Capturing USB with libpcap on Linux
I'm trying to capture full USB packets on a Raspberry Pi (kernel v4.9.59) using Wireshark (v2.2.6) and have followed the instructions on the Wireshark USB capture setup page. That page indicates that usbmon limits captured data on each block to about 30 bytes so I downloaded, built and installed the latest libpcap (version 1.8.1). Looking at the available interfaces I see usbmon1 listed but when I try to capture it I get the popup that /sys/kernel/debug/usb/usbmon/1t can't be opened (because it doesn't exist). If I load usbmon with modprobe and make /sys/kernel/debug/usb/usbmon/1t readable/writable by me then the capture works but I only get the first 32 bytes of each packet. What do I need to do to get Wireshark to capture using libpcap?
It looks as though there is a so called snaplength applied somewhere during capture. Are you using Wireshark to capture on the Pi, or another program, eg. tcpdump. What happens when you set a snaplength of 64 bytes for instance, does that change anything?
Jaap - at the time I did the original posting I was using Wireshark to do the capture. I kept digging after the post and found I could use tcpdump for the capture and then Wireshark to display the captured pcap file. I had seen snaplen mentioned in the man page but it said that the default length was 262144 so I hadn't used it. I just ran another test with it adding -s 512 (this is high speed USB packet size). Once again I found that I was only getting 30 bytes per packet. I used the data in the next Wireshark capture frame and scanned for it in the output file from my application and found it - not at address 0x200 as I would have expected (the start of the second 512 byte packet) but at address 0x1FE. This was the same pattern for the third packet, found ...(more)
While I don't see anything in the comments section here, I did receive an email earlier to check if ESL was disabled in the Analyze -> Enabled Protocols section. I did this and it was enabled (along with everything else).
That was a mispost, you can safely disregard that remark.
May I ask if you are receiving the data correctly (not on the usbmon interface, but the applications interface)? I really wonder why you would be seeing the data you're looking for in the next frame.
Since I'm currently not making any progress on the Wireshark / tcpdump end, I've changed direction slightly. The log data originates on a small board with a CPLD that decodes a Manchester encoded serial bit stream back into bytes and writes them to an FTDI FT232H which then sends it over the USB to the Raspberry Pi. I have reprogrammed the CPLD to generate an incrementing byte pattern and am rewriting my program on the Pi to simply read the data and verify the incrementing pattern. If it ever fails to verify with what's expected, the test stops immediately. I have a logic analyzer hooked up to the output of the CPLD and a homebrew USB high speed capture board inline on the USB. The logic analyzer will show the pattern that was generated, the capture board will show what actually went across the USB (if the problem ...(more)
The data received by my application is nearly always correct but should be 100%. Up until now I've been running short tests where 4MB is sent from the board where it's generated, to my application which saves it to a file. The logic analyzer, which has a capture depth of 4MB, captures what was sent and, when dropped data occurs, I can compare the logic analyzer listing to the file data and see which bytes were dropped. It had been my hope to capture the low-level kernel USB data so that I would have something to check between the two ends and narrow down the problem. Unfortunately what seems to be happening is that for every high speed USB packet (512 bytes) tcpdump currently only captures the first 30 bytes and discards the rest. This is the sort of behavior that describes the ASCII usbmon operation. But there ...(more)