usbmon broken

[Pekka Pessi]

The libpcap 1.0.0 traces from usbmon fail because libpcap does not take into account 16 extra padding bytes present in the mmap interface used in Linux kernels 2.6.21 and later.

Problem is fixed in libpcap development version, but it can be circumvented in 1.0.0 if libpcap avoids using mmap interface.

This bug makes tracing USB devices with wireshark and tcpdump effectively useless.

TEST CASE:
See comment #3 (https://bugs.launchpad.net/ubuntu/+source/libpcap/+bug/523340/comments/3)

[Brian Murray (brian-murray)]

I'd like to help out fixing this bug and 523349 but I'm really not quite certain how to test this. Is testing it using wireshark and usb interfaces sufficient or can I use tcpdump some how? Thanks for your patch!

[Michael Hofmann (mh21)]

Hi Brian,

for me the patch works, too. To test, do the following:
- install wireshark
- use lsusb to figure out which bus your usb mouse/keyboard etc. is on
- capture a trace of you pressing one button etc.:
  - with wireshark with the new libpcap
  - with the old libpcap
  - with cat /sys/kernel/debug/usb/usbmon/<bus>u
- if you have a usb keyboard, look in the USB_COMPLETE package for application data, it should be the same for the usbmon method and wireshark (the space key on my usb keyboard gives me 00002c00 00000000 for usbmon and the new libpcap, but 08000000 00000000 for the old one)

Hope this helps!

[Evan Huus (eapache)]

Michael, thanks for the steps. I can also reproduce this (on up-to-date Lucid), and the patch does solve the problem. Marking as confirmed.

Note to anyone else looking to reproduce this: libpcap does not "make install" the libraries where wireshark looks for them, you'll have to change the path in the makefile.

[Michael Richardson (mcr-sandelman)]

<email address hidden>. If a 1.0.1 release helps, then please speak up.

[Evan Huus (eapache)]

Not quite sure what's supposed to happen with this bug now? The new upstream version in Maverick fixes this, so I suppose that the general task should be marked as Fix Released. However it would still be good as an SRU for Lucid - what's the next step to get that looked at?

[Martin Pitt (pitti)]

The lucid task is still open; so if someone wants to prepare, teste, and upload a lucid SRU, that's fine.

[Michael Richardson (mcr-sandelman)]

I looked at the complexity and time required to produce a 1.0.1 with the correct fix, and it simply wasn't
within the tcpdump.org's ability to do.
We are in fact, overdue for a new regular release, which is late, so a 1.0.1 will not occur.

[Rolf Leggewie (r0lf)]

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".