I'm trying to reverse-engineer a BLE device that uses USB HID over GATT to communicate with the host. I can capture the traffic using usbpcap, but when loading the results into wireshark, the packets seem to contain the bytes representing the data that is going over the air (i.e. device descriptor), but the packets are not decoded according to USBHID protocol. Everything is decoded as USB, and only contain URB_INTERRUPT_IN, URB_BULK in/out and URB_CONTROL_OUT, while I'm looking for things like GET DESCRIPTOR Request/Response DEVICE. Is there an extra step I can take to get the packets formatted and parsed correctly?
There are a few characteristics in use. You have one characteristic which contains the Report Map. This is usually only read once when the device is paired. This map contains the layout/specification of the data which is later sent through the Report notifications. This is mostly "copy-paste" the specification from the USB spec into BLE.
Now, when you run HID-over-GATT and your Bluetooth controller talks to the Host over USB, what you will see in usbpcap is the ACL data which contains L2CAP data, which contains GATT data, which in turn contains the Report data for HID. Then the Bluetooth stack on the host will decode this and feed it into the kernel's HID parser.
I would suggest you to instead connect your HID-over-GATT device to an Android phone and then take a look at the HCI snoop log what happens, which is decodable in Wireshark (but it won't parse your HID data).
Related
In pipe and out pipe occur continuously within one frame when sending out pipe in Custom HID USB.
In pipe is requested periodically by the host pc every 1ms.
How can I modify the descriptor or FW that host pc don't ask for the in pipe within same frame when transfering out pipe?
Please let me know.
USB Communication Capture Image
It is not possible to modify the firmware or USB device descriptors to get that effect. That is not a standard feature of USB. You might try modifying the firmware of the device so that it can handle this situation (in fact I'm not sure why it would ever be a problem in the first place). You could also maybe modify the drivers/software you are using to communicate with the device.
I am new to Wireshark and capturing packets and all Stuff. Let me get it to the straight.
I have a hardware which outputs its data over Ethernet using a UDP Broadcast. I Can directly plug a Ethernet Cable to a In-line RJ-45 Coupler (attached to the hardware) and my PC Running Wireshark.
REQUIREMENTS : I need to Capture RAW Data which my hardware is broadcasting so that it can be given to other team so as to know the format in which it is providing for further post processing.
What I Did : Initially , I connected the Ethernet Cable from my home and Started capturing the packets which didn't make any sense to me.
Can you please point out if I am going in correct direction ? Sorry if its a very basic question, but raw data from the hardware is important for my further tasks....
As far as any software can understand a wire you will always get a packet. Between you (in front of a computer) and the cable in the in the RJ-45 jack sits a NIC (network interface controller, i.e. your network card).
Your Ethernet NIC will read the current on the cable (in manchester encoding for ethernet) and synchronize itself to any Ehternet traffic on that cable. What does "synchronizing" mane in there? In front of any Ehternet traffic come 64 alternate bits of 0s and 1s which are meant to synchronize the clocks on both communicating NICs. Without proper clock synchronization some data may be misinterpreted.
But why I am talking about clock synchronization? Because if you want the data as RAW as it is on the cable you will not get it. A NIC will never send any synchronization bit to the rest of the computer, therefore it is absolutely impossible to read exactly what is on the cable by using software.
On the other hand I find hard to believe you want the RAW data as RAW as that. After the synchronization bits come an Ethernet encapsulated packed. Yup, Ethernet uses packets. They're link layer packets (layer 2 in OSI).
And wireshark gives you exactly that (in most cases, see note at the end for two exceptions to this rule): every Ehternet packet that the NIC understands, manages to sync, and manages to read without collision is sent to the kernel and then read by wireshark. A cable has electrical interference and has no provision against collisions (it's just a piece of cooper!) therefore the NIC abstracts things like interferences and collisions.
I'll repeat it once more: After abstracting the synchronization bits, sender collisions (which turn the cable into one huge interference) and plain interferences; all that remains is a stream of packets, one after the other.
Extra Notes
NICs sometimes do ignore some Ethernet packets: packets that are not directed to their MAC. This can be changed by enabling promiscuous mode (available in most NICs). This is irrelevant for broadcast packets.
There are exception to the rule of wireshark getting all the traffic coming from the NIC:
If the traffic comes incredibly quick, wireshark may drop out of kernel schedule and not see some packets. It happens, nothign can be done about it.
If you listen on all interfaces (as opposed to selecting a single interface to listen at), wireshark will strip the Ethernet (or Wifi) headers. This is a wireshark hack needed to make output files uniform (and possible to be read by other applications).
TL;DR, wireshark output (pcap) is pretty much just the stream of packets that it got from the NIC, one after the other. That is as RAW as you can get with software.
I'm in trouble with programming my Arduino. I've two XBee Series 2 Modules and an Arduino UNO. I use the XBee-API library from: http://code.google.com/p/xbee-api/.
I generate three RemoteATRequest Packets (0x17) to control a Digital Pin of the Remote Sleepy Node and send it out of a SoftwareSerial to the XBee Coordinator which is plugged via a Sparkfun XBee Arduino Shield (https://www.sparkfun.com/products/10854) to the Arduino UNO. The Communication works fine. Every Request Packet is sending out to the Remote. And for every Request Packet a Remote Packet is received. I checked this with a Serial Monitor and a RS232<-> TTL Converter. But in my Arduino Software it seems to be that only one Remote Packet is received. Curious is the point that when I send the Request Packets in the time the Remote is sleeping than I read three Response if it is awake and takes the Requests from the Coordinator.
Does anyone try the same or hase the same problems? I've tried so much until know another Baudrate, delays befor sending out. Nothing works.
My recollection of ZigBee and/or 802.15.4 is that the parent node for a sleepy end device will only hold/queue a single frame for when the sleepy device wakes up. And note that in ZigBee it's only guaranteed to queue it for 7.5 seconds. You may need to modify your code to send a single Remote AT Request at a time, and wait for the response before sending another.
This page has a good description about how the MAC layer works:
Once the frame is assembled, there are actually two ways to send it.
If its going to another router or an end device whose receiver is
always on, the frame will be sent directly via the radio. Otherwise,
if the destination is a sleepy end device, the frame will need to be
sent as an indirect transfer. The frame will go to the indirect queue
until the destination device wakes up and polls the parent. Once the
poll comes in, the frame will get sent to the destination.
It would be great if the XBee module supported a frame type that contains multiple AT commands, but as far as I can tell, that isn't an option.
Does anyone know how to create a raw socket to a USB device? Like you can create raw sockets to ethernet devices, I would like to send/receive arbitrary data to a USB device.
Depends on the platform - you need a low level USB library.
Either http://sourceforge.net/projects/libusb/ or http://sourceforge.net/projects/libusb-win32/ is a good place to start
ps. It isn't a socket as such, sockets are specific to networks
You can write to the EndPoint using a Raw Socket but a certain protocol needs to be followed for the device to physically accept and reply to commands.
Depending on how the protocol is written you may be able to use a a RawSocket and some Usb sniffer to replay the data to the EndPoint but most devices employ a Timestamp and handshake process which needs to be performed dynamically for each connection and usually involves querying the device state and using the information to complete the handshake along with other information depending on the protocol of the device in question.
When a GSM modem is receiving voice(i.e., multiple wave files continuously) in the voice path, how will the modem able to identify the completion of a single wave file? Is there any software that could perform this?
The modem doesn't actually send wave files (in the sense of .wav files), because these require a header that describes how long the file is. Instead, the modem keeps sending raw data until either the call ends or the computer tells it to stop. The modem signals the end of the data with a DLE byte followed by a ! - see the wikipedia article about voice modem commands for details of this (and for how a DLE byte is sent in the datastream).
As for converting the data to .wav or another usable format: many audio conversion programs can do this; soxis one such command-line program.
A GSM mobile station may support different bearers. Depending on device capability this includes
voice
circuit switched data
packet switched data
A mobile phone typically supports voice, CS data and PS data. A GSM modem may support PS data only. Each of these bearers are implemented differently in order to utilize the radio channel effectively.
You can transport a WAV file via an packet switched bearer, however then it will be transported using IP technology. This needs an application on both endpoints handling the transport and the presentation to the user, e.g. playout.
A voice bearer supplies a continuous audio stream, starting with connecting the call and ending with terminating the call. GSM does not support discrete portions of audio on the voice bearer. Playing a WAV file on the voice bearer is a non-standard functionality for virtually all commercial devices. You may need to find test devices supporting this.
If you use the voice bearer to play out the WAV file like a normal telephone call and want to detect completion of a playout you may detect a pattern in the audio (requires an algorithm to calculate similarity since your WAV file will be encoded several times and may be mixed with noise) or use some sort of out-of-band signalling, some phones support dual mode, i.e. running voice bearer and PS bearer in parallel. Both not trivial to do.