I am using dumpcap (v1.12.1) on a Raspberry Pi 3 Model B to monitor incoming logging information over a full speed USB link attached to an embedded project. Input data rate is approximately 70KB/sec. The packet protocol is rather simple - a single byte of command (identifying the log source), a 16-bit byte count followed by some number of bytes of data. This is being sent over a Bulk Endpoint connection and byte counts are exactly 0x3000 for one log source and anywhere in the range 0x200-0x230 for the other. On the Pi I am using the command "dumpcap -i 8 -b filesize:10000 -b files:20 -w /mnt/Tap/logServer/LOGs/Wireshark/capt.pcap" to create a rolling list of 20 10MB files before the oldest is overwritten. When I compare the Wireshark display of a pcap file to the binary file of logged data, I'm seeing the first 32 bytes of data following the protocol header, followed by 96 bytes of data that shows up in the log file but not on the Wireshark display. This repeats through the end of each log packet - 32 bytes displayed, 96 bytes missing. I have checked dozens of packets and it's never more or less - always the same 32/96 mix. While I've used Wireshark for a number of years, I am relatively new to using it for USB and I am very new to using dumpcap, so I suspect I have something messed up in the configuration. I've been through the dumpcap manpage but don't see anything that might lead to what I'm seeing. I'd be grateful if anyone has any ideas on what I'm doing wrong. Thanks, Dave asked 17 Dec '16, 11:36  DaveHarper showing 5 of 22 show 17 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Can you share a capture in a publicly accessible spot, e.g. CloudShark, Google Drive, Dropbox etc.?
@grahamb: Will do - let me get a pcap file, along with a log file and a README together and I will post as to where when all is in place. May take a few minutes.
@grahamb: If I've done everything right the files are now available on: https://drive.google.com/drive/folders/0B_96KgN-BZm4T2tQbGRMWXN4TkE
Please let me know if you can/can't access them okay and if it's what you need.
The files require permission to download. Try cloudshark?
Cloudshark was the first thing I tried but there was a 2MB limit and the pcap file is around 10MB. Let me try working on the permissions or find another site.
Found a site that is not password protected that will keep the files for a week. There are separate download links for the three files: https://www.sendspace.com/file/m4lv8l https://www.sendspace.com/file/84v05b https://www.sendspace.com/file/dx3a2m
Google Drive is OK but you have to set the sharing permissions to "Anyone with the link".
Thanks - found where to do this and changed the permissions on the folder. Should be open now.
I agree with your findings.
A further confirmation is the frame 10400 has the data (32 bytes) starting at offset 70C3D1, but the next incoming data frame 10402 has data at offset 70C451, so 128 bytes on, but there were only 32 bytes in frame 10400 so 96 missing again.
As to where the bytes have gone, I would suspect the capture library, either dropping frames, or truncating the data as it doesn't seem to be in the capture.
First, thank you for taking the time to go through a rather massive amount of data to confirm what I'm seeing. I am a bit surprised at your conclusions - I was sure it was something I was doing wrong, otherwise I would have thought this would have been seen before. I assume this should be reported so if you will respond as such, I'll mark it as the answer and file a bug report.
This issue is against what component to file the bug report. I guess it's possible that it's in dumpcap which is part of the Wireshark project, but I think it's more likely to be in your capture library whatever that is.
I also used a display filter such as
usb.capdata contains aa:bb:cc:dd:ee:ffto search for the binary bytes 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff. There's is no limit (as far as I can tell) to the number of bytes you can search for."This issue is against what component to file the bug report". I'm basically a hardware guy trying to use to the tools to track down an issue that occurs every few days or so. Any tips on how to determine what to check next? The dumpcap application is running under a Debian version of Linux on the Raspberry Pi and I need to run the command "modprobe usbmon" to be able to run the tools. Is "usbmon" the capture library you're referring to? Unfortunately, I'm pretty ignorant of what is actually happening "under the covers" so I don't really know where to start. While I will likely eventually capture what I need to track down my problem, that might not be the case for someone else. So I'd like to do what I can to help resolve things, especially since I seem to have a repeatable test case that shows the problem.
We're at the stage now where I only know enough about Linux capturing and usb capturing to be dangerous, not helpful.
Hopefully someone else might chip in.
The capture library is libpcap. It captures atop many different capture mechanisms, including Linux's "usbmon" USB traffic capture mechanism; "usbmon" is a Linux kernel module.
If a Linux USB capture is chopping off packet data at 96 bytes or so, that might be because only the "text mode" usbmon mechanism is working. What is the version of the kernel on the Raspberry Pi? If it's older than 2.6.21, the kernel doesn't support the "binary mode" usbmon mechanism, and you won't be able to get the full data. What does
ls -l /dev/usbmon*print on the Raspberry Pi?The ls -l /dev/usbmon* prints:
I also checked the kernel version with uname -r and it printed: 4.4.13-v7+ which should be fairly recent (it was installed within the last six months and I've updated it since then).
What does
dumpcap -Dprint on the RPi?The dumpcap -D prints out 8 lines. The first seven are other interfaces (eth0, etc.). The last line is usbmon1.
If you have tcpdump on the RPi, what happens if you 1) run
tcpdump -h, 2) runtcpdump -Dand 3) try to capture withtcpdump -i usbmon1 -c 500 -w /mnt/Tap/logServer/LOGs/Wireshark/tcpdump-capt.pcap? Does the file tcpdump writes have the same problem?Installing now...
Okay - tcpdump -h prints: tcpdump version 4.6.2 libpcap version 1.6.2 OpenSSL 1.0.1t 3 May 2016
along with the usage information.
tcpdump -D prints: 1.eth0 [Up, Running] 2.any (Pseudo-device that captures on all interfaces) [Up, Running] 3.lo [Up, Running, Loopback] 4.wlan0 [Up] 5.bluetooth0 (Bluetooth adapter number 0) 6.nflog (Linux netfilter log (NFLOG) interface) 7.nfqueue (Linux netfilter queue (NFQUEUE) interface) 8.usbmon1 (USB bus number 1)
As for doing a capture, that's going to take a few minutes to get another run set configured and started. I will post as soon as I have run it and checked the result.
I just finished the test and I am seeing the same thing in tcpdump that I saw with dumpcap.