I am using pyshark to analyze a Wireshark capture. As you can see in the screenshot there is a packet containing two MMS subpackets. But when I load capture with wireshark and watch the pyshark representation of thepacket with a debugger, there is only the data of the first MMS packet.
Can anyone tell me how I can access the data of the second subpacket?
Related
Say I have an USB device, a camera for instance, and I would like to load the image sequence captured by the camera to the host, using libusb API.
It is not clear to me for the following points:
How is the IN Endpoint on the device populated? Is it always the full image data of one frame (and optionally plus some status data)?
libusb_bulk_transfer() has a parameter length to specify how long is the data the host wants to read IN, and another parameter transferred indicating how much data actually had been transferred. The question is: should I always request the same amount of data that the IN Endpoint would send? If so, then what would be the case where transferred was smaller than length?
How is it determined how much data would be sent by the In Endpoint upon each transfer request?
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).
Digging around with/for HID reports, I ran into a strange problem within a USB HID device. I'm implementing an HID class device and have based my program on the HID USB program supplied by Keil. Some codes have been changed in this project and it seems working fine with 32 bytes input and 32 bytes output reports. Somehow, after thousands times data transferring, the Endpoint 1 out would hang and become a bad pipe. Then I searched the google for some tips, a topic remind me that we should write a data length zero packet after sending a length of packet match what you defined in the report description. But it's not working for me. Then I write a data length zero to the control pipe after I receive a out packet and magically, it works! It would never hang after million times transferring!
Here is my question: Why does it works after writing a data length zero to a control pipe. The data transferring in the out pipe should have no relationship with the data in the control pipe. It confuses me!
If you transfer any data that is less than the expected payload size, you must send a Zero Length Packet to indicate that data has transferred.
But it depends heavily on the implementation on the host controller, and not all devices follow the specification to the point and may stall.
Source:
When do USB Hosts require a zero-length IN packet at the end of a Control Read Transfer?
I am trying to build my own client RTMP library for an app that I am working on. So far everything has gone pretty successfully in that I am able to connect to the RTMP server negotiate the handshake and then send all the necessary packets (FCPublish Publish ETC) then from the server i get the onStatus message of NetStream.Publish.Start which means that I have successfully got the server to allow me to start publishing my live video broadcast. Wireshark also confirms that the information (/Data packetizing) is correct as it shows up correctly there also.
Now for where I am having some trouble is RTMP Chunking, going off the Adobe RTMP Specification on page 17 & 18 shows an example of how a message is chunked. From this example I can see that it is broken down based on the chunk size (128 bytes). For me the chunk size gets negotiated in the initial connect and exchange which is always 4096 bytes. So for when I am exchanging video data that is larger than 4096 bytes I need to chunk the message down sending the RTMP packetHeader combined with the first 4096 bytes of data then sending a small RTMP header which is 0xc4 (0xc0 | packetHeaderType (0x04)) combined with 4096 bytes of video data until the full packet specified by the header has been sent. Then a new frame comes in and the same process is repeated.
By checking other RTMP client example written in different languages this seems to be what they are all doing. Unfortunately the ingest server that I am trying to stream to is not picking up the broadcast video data, they dont close the connection on my they just never show video or any sign that the video is right. Wireshark shows that after the video atom packet is sent most packets sent are Unknown (0x0) for a little bit and then they will switch into Video Data and will sort of flip flop between showing Unknown (0x0) and Video Data. However if I restrict my payload max size to 20000 bytes Wireshark shows everything as Video Data. Obviously the ingest server will not show video in this situation as i am removing chunks of data for it to be only 20k bytes.
Trying to figure out what is going wrong I started another xcode project that allows me to spoof a RTMP server on my Lan so that I can see what the data looks like from libRTMP IOS as it comes into the server. Also with libRTMP I can make it log the packets it sends and they seem to inject the byte 0xc4 even 128 bytes even tho I have sent the Change Chunk size message as the server. When I try to replicate this in my RTMP client Library by just using a 128 chunk size even tho it has been set to 4096 bytes the server will close my connection on me. However if change libRTMP to try to go to the live RTMP server it still prints out within LibRTMP that it is sending packets in a chunk size of 128. And the server seems to be accepting it as video is showing up. When I do look at the data coming in on my RTMP server I can see that it is all their.
Anyone have any idea what could be going on?
While I haven't worked specifically with RTMP, I have worked with RTSP/RTP/RTCP pretty extensively, so, based on that experience and the bruises I picked up along the way, here are some random, possibly-applicable tips that might help/things to look for that might be causing an issue:
Does your video encoding match what you're telling the server? In other words, if your video is encoded as H.264, is that what you're specifying to the server?
Does the data match the container format that the server is expecting? For example, if the server expects to receive an MPEG-4 movie (.m4v) file but you're sending only an encoded MPEG-4 (.mp4) stream, you'll need to encapsulate the MPEG-4 video stream into an MPEG-4 movie container. Conversely, if the server is expecting only a single MPEG-4 video stream but you're sending an encapsulated MPEG-4 Movie, you'll need to de-mux the MPEG-4 stream out of its container and send only that content.
Have you taken into account the MTU of your transmission medium? Regardless of chunk size, getting an MTU mismatch between the client and server can be hard to debug (and is possibly why you're getting some packets listed as "Unknown" type and others as "Video Data" type). Much of this will be taken care of with most OS' built-in Segmentation-and-Reassembly (SAR) infrastructure so long as the MTU is consistent, but in cases where you have to do your own SAR logic it's very easy to get this wrong.
Have you tried capturing traffic in Wireshark with libRTMP iOS and your own client and comparing the packets side by side? Sometimes a "reference" packet trace can be invaluable in finding that one little bit (or many) that didn't originally seem important.
Good luck!
I am streaming raw UDP packets (rf data) from GNU Radio to Octave (or any other program). The data consists of 390625 4 byte floats per second. This is 1562500 bytes per second. When GNU Radio streams UDP, there is no header or sequence number in the UDP data, it's just raw floats. Because this is localhost to localhost, I am able to use a very large MTU.
Attached is a screenshot of Wireshark after right clicking and doing "Follow UDP Stream". There is a "blank" part of the Hex Dump at 0x6F38C8. I don't understand what this means? (I know that UDP does not provide reliable delivery and packets can be dropped and arrive out of order at any moment). Any help would be great!
The blank part is simply used as a barrier to differentiate between 2 UDP packets, solely for your convenience.
If you track down that exact data in the normal wireshark window you'll notice that the data before the blank part belongs to a certain UDP packet and that the data after the blank part belongs to the subsequent UDP packet.
The HEX numbers on the left specify the offset of the first byte of the line from the beginning of the stream in that direction (i.e. in the half blank line, the byte 0x08 has 0x6F38C8 bytes sent before it in that direction). Since the half blank line has just 8 bytes, the offset of the next line is 0x6F38C8 + 0x8 = 0x6F38D0. This is another indicator that the blank part isn't used as a filler for certain data that couldn't be represented due to some obscure reason.
Note that it would be impossible for wireshark to know whether data is lost and represent it to you in any manner, since UDP is unreliable (that is, unless the underlying protocol maintains certain counters by itself, and is parsed by wireshark).