Created attachment 23496 [details] URBs captured through the text interface There is a difference in binary data what is reported through the text interface /sys/kernel/debug/usb/usbmon/1u and through /dev/usbmon1. The URB data is wrong on binary interface. How to reproduce: 1. modprobe -k usbmon 2. mount debugfs /sys/kernel/debug/ -t debugfs 3. Open two xterm windows: "A" and "B" 4. On "A" execute: cat /sys/kernel/debug/usb/usbmon/1u >usbmon_1u.txt 5. On "B" execute a patched version of Wireshark. Redirect stdout to usbmon_binary_wireshark.txt . The patch just prints out what Wireshark reads from /dev/usbmon1 in human readable form. The lines starting with pcap_read_linux_usb_pseudoheader() show the pseudoheader. Lines starting with libpcap_read_rec_data() show the URB packet data. 6. Start capturing in Wireshark on USB bus 1. 7. Plug in Genius NetScroll 110 USB mouse to USB bus 1. Current result: The URBs captured through text interface seems to be OK, the URBs captured on binary interface are bad. Expected result: The same URB data is read through the text interface and the binary interface.
Created attachment 23497 [details] URBs captured through binary interface
Created attachment 23498 [details] caputre data saved from Wireshark
Created attachment 23499 [details] Patch for Wireshark to dump URBs on stdout
Created attachment 23500 [details] Linux kernel configuration 2.6.32-rc5
Created attachment 23501 [details] Some debug messages for usbmon binary interface
Created attachment 23502 [details] Repeated with wireshark
Created attachment 23503 [details] the debug messages from dmesg The attachment 23502 [details] and this one was created at the same time.
On Fri, Oct 23, 2009 at 07:33:48AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=14456 > > Summary: usbmon: binary interface reports URB data wrongly Can you please post this information on the linux-usb@vger.kernel.org mailing list so that the linux usb developers can comment on it?
Created attachment 23511 [details] Some more debug messages
Note that there is one additional layer between kernel and Wireshark: this is libpcap from http://www.tcpdump.org/ .
Created attachment 23512 [details] Patch for Wireshark to dump URBs on stdout (typo corrected)
Created attachment 23519 [details] strace verbose output while running Wireshark I checked usbmon from http://people.redhat.com/zaitcev/linux/usbmon-5.4.tar.gz which works correctly without debugfs and usbfs mounted. The packages are shown correctly. Wireshark can only start capturing if usbfs is mounted, debugfs is not necessary. I run Wireshark with strace, the output is attached. The packages are captured wrongly. You might also want to see attachment 23511 [details] which is created from dmesg with a patched usbmon kernel module. On that log the function calls are also shown.
(In reply to comment #12) > You might also want to see attachment 23511 [details] which is created from > dmesg with a patched usbmon kernel module. On that log the function calls are > also shown. I mean attachment 23503 [details]...
Created attachment 23520 [details] stdout of the previous Wireshark capture
Created attachment 23521 [details] the bad capture file saved from Wireshark
Thanks, that helps a lot. So, Wireshark (libpcap) does this: 4849 open("/dev/usbmon1", O_RDONLY|O_LARGEFILE) = 3 ......... 4849 select(4, [3], NULL, NULL, {0, 250000} <unfinished ...> 4849 <... select resumed> ) = 1 (in [3], left {0, 241497}) 4849 ioctl(3, 0xc00c9207, 0xbfc161a0) = 0 <---- 32 bit MON_IOCX_MFETCH 4849 ioctl(3, 0x9208, 0x1) = 1 <---- MON_IOCH_MFLUSH 4849 time(NULL) = 1256456277 4849 select(4, [3], NULL, NULL, {0, 250000}) = 1 (in [3], left {0, 247121}) 4849 ioctl(3, 0xc00c9207, 0xbfc161a0) = 0 4849 ioctl(3, 0x9208, 0x1) = 1 And usbmon(8) does this: open("/dev/usbmon0", O_RDWR) = 3 ioctl(3, 0x4018920a, 0x7fff258c5c70) = 0 <---- MON_IOCX_GETX write(1, "26092318 0.800486 S Ci:1:001:0 s "..., 58) = 58 ioctl(3, 0x4018920a, 0x7fff258c5c70) = 0 write(1, "26092318 0.800791 C Ci:1:001:0 0 "..., 46) = 46 It's one of: - I never tested MFETCH implementation and it's buggy, or - Paolo never tested his code for binary API and it's buggy, or - Something bitrotted and Paolo's code stopped working I see from the text output that it's a 32-bit kernel, so there are no issues with the compat implementation.
Upgrading to libpcap git 339d28cefc11bbadaa92005b4f7b365f4732432c ("git clone git://bpf.tcpdump.org/libpcap") fixes the problem.
Thanks a lot. I already started writing tests but you pre-empted that. Let's close the bug.