This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

How to get Wireshark to see usbmon0?

0

Hello all, thank you for this forum.

How to get Wireshark to see usbmon0?  ls -l /dev/usbmon shows 

crw-r--r-- 1 root root 248, 0 Jan 10 14:50 /dev/usbmon0 
crw-r--r-- 1 root root 248, 1 Jan 10 14:50 /dev/usbmon1 
crw-r--r-- 1 root root 248, 2 Jan 10 14:50 /dev/usbmon2

but Wireshark only sees the latter two.

1. We have a piece of boat gear (RayMarine C120W) that bridges NMEA 0183 (ASCII) and EtherNet ("SeaTalk-HS") data for transmission to Windows software (RayTech Navigation System—RNS). The bridged data are wired to a DB-9F chassis connector near the laptop. We did have a Serial to Ethernet cable that connected to an older laptop running the software that had an Ethernet Socket. It worked fine.

2. We have not touched the boat wiring, but have lost the cable and necessarily moved the software to a new laptop (openSUSE Leap 42.1 Linux) that does not have an Ethernet socket, only USB.

3. We have a Gigaware 2603487 USB-A to Serial Cable. It is recognized by the laptop and connected to ttyUSB0. We can read that port at the command line interface—CLI—with cat /dev/ttyUSB0 and see the NMEA 0183 ASCII sentences but not the Ethernet stream. 

3.1 I understand that the EtherNet traffic is higher frequency and multiplexed, yada yada, so will address that aspect ("EtherNet over USB") in due course, but first we need Wireshark to see the basic USB data that we can see on the CLI (presumably on usbmon0) to ensure that Wireshark is reading the USB connection.

4. We have laboriously followed https://wiki.wireshark.org/CaptureSetup/USB and many of its adherents, particularly http://stackoverflow.com/questions/31054437/how-to-install-wireshak-on-linux-and-capture-usb-traffic — yes, they misspelled Wireshark. As a result we have:

4.1 Sorted out usbmon. It needs to be restarted after each reboot (modprobe usbmon), a PITA we'll address later.

4.2 Added the requisite capabilities to dumpcap

4.3 Changed permissions as directed (644) on /dev/usbmon*, added the wireshark group and added the user to the group.

4.4. Configured Wireshark for non-root use, but that shows the same results as running it as root (yes, I know, a no-no).

5. https://wiki.wireshark.org/CaptureSetup/USB says the special "usbmon0" interface receives events from all USB buses.

5.1 After a new modprobe usbmon after a reboot ls -l /dev/usbmon* returns

crw-r--r-- 1 root root 248, 0 Jan 10 14:50 /dev/usbmon0 
crw-r--r-- 1 root root 248, 1 Jan 10 14:50 /dev/usbmon1 
crw-r--r-- 1 root root 248, 2 Jan 10 14:50 /dev/usbmon2

so others (user, wireshark group) should be able to read.

5.2 So indeed usbmon0 exists but it does not appear in Wireshark. Wireshark only shows usbmon1 and usbmon2.  Neither has any interesting traffic, certainly not the ASCII stream that we can see on the CLI.

6. We have attempted using a USB connected EtherNet to USB adapter with a Serial to Ethernet cable. It is recognized by the OS and Wireshark sees it as eth0 but there is zero traffic on it.

We can proceed further with EtherNet over USB once we have determined that Wireshark can read usbmon0 (ttyUSB0).

How to get Wireshark to see usbmon0?

Thanks in advance. Thank you again for this excellent forum. Happy New Year.

Kind regards, Andy

asked 10 Jan '17, 16:56

alavarre's gravatar image

alavarre
11●1●1●5
accept rate: 0%

edited 17 Jan '17, 11:25

cmaynard's gravatar image

cmaynard ♦♦
9.4k●10●38●142

1

First things first, can you post tshark -v output, especially the "Compiled with" and "Running on" paragraphs?

(17 Jan '17, 11:28) cmaynard ♦♦
1

According to https://www.kernel.org/doc/Documentation/usb/usbmon.txt:

The character device is usually called /dev/usbmonN, where N is the USB bus
number. Number zero (/dev/usbmon0) is special and means "all buses".
Note that specific naming policy is set by your Linux distribution.

... so presumably if there's USB traffic then it should be visible on one of the other usbmonN interfaces, even if you can't capture on usbmon0.

(17 Jan '17, 11:39) cmaynard ♦♦

cmaynard, thank you:

[email protected]:~> tshark -v
TShark 1.12.13 (Git Rev Unknown from unknown)
Compiled (64-bit) with GLib 2.44.1, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux), with libnl 3, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.1, with MIT Kerberos, with GeoIP.

Running on Linux 4.1.36-44-default, with locale en_US.UTF-8, with libpcap
version 1.5.3, with libz 1.2.8. Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz


Built using gcc 4.8.5.

===== I seem to have successfully gotten usbmon to load on root (lsmod shows it) but running WS as user does not show any usbmon, running WS as root only shows usbmon1 and usbmon2, neither shows interesting traffic, just stuff like GET STATUS XXXX, GET DESCRIPTOR XXXX, etc.

Thanks again. Andy

(17 Jan ‘17, 11:52) alavarre
1

neither shows interesting traffic

Are you sure? What happens when you disconnect/connect the device while capturing?

(Find out which bus the device is attached to via something like, lsusb -v | grep “^Bus.*Device” to know which interface, usbmon1 or usbmon2 you should be capturing on.)

(17 Jan ‘17, 12:05) cmaynard ♦♦

Hello thank you again.

Yes, quite sure.

spectre:~ # lsusb -v | grep “^Bus.*Device” Bus 001 Device 013: ID 05ad:0fba Y.C. Cable U.S.A., Inc.

There are many others, of course, but this one disappears from lsusb when I unplug it.

As noted, the user sees no usbmonN. Root sees usbmon1 and usbmon2. The traffic on both is similar: URB_BULK in URB_BULK out etc. All system control signals no actual user data…

Thank you also for the comment on usbmon0. I was thinking that this would pick up ASCII (NMEA) or Ethernet packets that perhaps usbmon1&2 mght not…

(17 Jan ‘17, 14:12) alavarre

Chris, I see you are in East Greenwich. I’m in Newport… :-)

(17 Jan ‘17, 14:15) alavarre

I used to have a USB NMEA-capable device, and I vaguely recall monitoring messages, perhaps with something like minicom, but it’s been a long time since I’ve done that and so I don’t recall the specifics. Even if I did, I’m not sure it’d help you with your device anyway.

Close - I’m in West Greenwich. I guess you are 30 minutes away from me, but of course nearly everything in RI is 30 minutes away. :)

(17 Jan ‘17, 14:27) cmaynard ♦♦

I used to have a USB NMEA-capable device, and I vaguely recall monitoring messages, perhaps with something like minicom, but it’s been a long time since I’ve done that and so I don’t recall the specifics. Even if I did, I’m not sure it’d help you with your device anyway.

I can read the device with spectre:~ # stty -F /dev/ttyUSB0 4800 spectre:~ # cat /dev/ttyUSB0

but all I get is ASCII, not any Ethernet: $APHDG,93.8,,,,6A $APHDG,93.8,,,,6A $APRSA,-26.60,A,,*11

I’ve tried higher baud rates without success…

Close - I’m in West Greenwich. I guess you are 30 minutes away from me, but of course nearly everything in RI is 30 minutes away. :)

:-) I almost never leave the island except once a month for beer I can’t get in RI… :-)

(17 Jan ‘17, 16:36) alavarre
1

but Wireshark only sees the latter two

What does tcpdump see if you do tcpdump -D and, just to make sure, sudo tcpdump -D (do both of them)?

(17 Jan ‘17, 18:26) Guy Harris ♦♦
1

I can read the device with spectre:~ # stty -F /dev/ttyUSB0 4800 spectre:~ # cat /dev/ttyUSB0

/dev/ttyUSB0 is NOT the usbmon0 device. It’s a USB device that presents itself as a serial port (for example, a USB-to-serial converter, or perhaps a serial port on the computer if it’s connected to the host over USB).

(17 Jan ‘17, 18:28) Guy Harris ♦♦

Guy Harris, thank you.

As user andy [email protected]:~> tcpdump -D

1.bluetooth0 (Bluetooth adapter number 0)
2.dbus-system (D-Bus system bus)
3.dbus-session (D-Bus session bus)

As root: spectre:~ # tcpdump -D

1.wlan0                                                                                                                                                                              

2.bluetooth0 (Bluetooth adapter number 0)                                                                                                                                            

3.nflog (Linux netfilter log (NFLOG) interface)                                                            o                                                                          

4.nfqueue (Linux netfilter queue (NFQUEUE) interface)                                                                                                                                

5.dbus-system (D-Bus system bus)                                                                                                                                                     

6.dbus-session (D-Bus session bus)                                                                                                                                                   

7.usbmon1 (USB bus number 1)                                                                                                                                                         

8.usbmon2 (USB bus number 2)                                                                                                                                                         

9.any (Pseudo-device that captures on all interfaces)                                                                                                                                

10.lo


So I need to go back and review my setup to allow user andy to access the devices…

/dev/ttyUSB0 is NOT the usbmon0 device. It’s a USB device that presents itself as a serial port (for example, a USB-to-serial converter, or perhaps a serial port on the computer if it’s connected to the host over USB).

Yes, thank you. In my case the laptop does not have a DB-9 serial connector, only three USB connectors. When I plugin a USB cable it manifests itself (dmesg) as /dev/ttyUSB0 and I can then see traffic on ttyUSB0 (cat /dev/ttyUSB0). Since usbmonN are virtual devices, shouldn’t one or the other see the traffic on ttyUSB0?

I understand that usbmon0 is a virtual port combining the traffic from all USB devices. Why does it not appear in tcpdump?

Thans all again. Learning is a painful process, but easy once you know how…

Cheers, Andy

(18 Jan ‘17, 09:23) alavarre

OK, this is a libpcap problem; Wireshark - and tcpdump - are stuck with it.

What happens if you try doing tcpdump -i usbmon0 -w /tmp/usb-all.pcap, cause some USB traffic to appear, stop tcpdump with ^C, and then read /tmp/usb-all.pcap in Wireshark?

(18 Jan ‘17, 16:55) Guy Harris ♦♦

Guy, thank you again.

As user andy: Permission denied.

Yes, I know I have to work on that.

As root:

 spectre:~ #  tcpdump -i usbmon0 -w /tmp/usb-all.pcap


tcpdump: listening on usbmon0, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 65535 bytes

Nothing else happens until I do ^C, which then gives me:

^C

0 packets captured
0 packets received by filter
0 packets dropped by kernel

How do you know al this stuff!!!

(18 Jan '17, 18:29) alavarre
showing 5 of 13 show 8 more comments

One Answer:

2

The fact that usbmon doesn't show up in Wireshark is a libpcap bug; a fix was checked in on October 14, 2015, which means the only libpcap release that has it is libpcap 1.8.1. I don't know which releases of which Linux distributions have that version of libpcap, but yours doesn't.

This means that programs using libpcap, such as tcpdump and Wireshark, won't get usbmon0 in the list of devices if they ask libpcap for a list of devices.

It doesn't mean that you can't capture on it...

...unless you're using a program like Wireshark, which currently doesn't let you type in the name of a device on which to capture. (Much older versions supported that, but that ability was removed. I'm not sure removing that ability was a good idea, for various reasons, including this libpcap bug.)

So, for now, you're stuck with using tcpdump, dumpcap, or TShark to capture on usbmon0, and then read the file with Wireshark; they're command-line tools, and let you type anything as an interface name, even if it's not in the list of known interfaces that libpcap provides.

As for why you're not getting any traffic even if you capture on usbmon0, that's a separate issue - what happens if, for example, you plug a USB drive into the same USB slot while tcpdump is running?

(And, in answer to your final question, the answer is "I'm a core Wireshark, libpcap, and tcpdump developer, and I'm the one who committed the October 14, 2015 fix, and also was working in the list-the-devices code in libpcap to change the order in which devices show up, in order to, among other things, have all the usbmon devices appear together, so that code was somewhat fresh in my mind.")

answered 18 Jan '17, 20:12

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k●3●35●196
accept rate: 19%

Guy, thanks again. I'm learning a lot about sniffing!

I don't know which releases of which Linux distributions have that version of libpcap, but yours doesn't.

Thanks for the explanation. Our version under openSUSE 42.1 is libpcap1 v1.5.3-5.1-x86_64

It doesn't mean that you can't capture on it...

  I now can  so do.

I'm not sure removing that ability was a good idea, for various reasons, including this libpcap bug.)

  Agreed...

So, for now, you're stuck...

  All good. I can do both
    spectre:~ # tshark -i usbmon0           
        Running as user "root" and group "root". This could be dangerous.

Yes I need to review my user setup. I do not have permission to listen as user:

        [email protected]:~> tcpdump -vv -i usbmon0 -w /Downloads/dump.pcap 
                    /usb/usbmon/0t: Permission denied

So, continuing for now as root:


spectre:~ # tcpdump -vv -i usbmon0
    tcpdump: packet printing is not supported for link type USB_LINUX_MMAPPED: 
    use -w   



spectre:~ # tcpdump -vv -i usbmon0 -w /Downloads/dump.pcap

As for why you’re not getting any traffic even if you capture on usbmon0, that’s a separate issue - what happens if, for example, you plug a USB drive into the same USB slot while tcpdump is running?

spectre:~ # tcpdump -vv -i usbmon0 -w /Downloads/dump.pcap
tcpdump: listening on usbmon0, link-type USB_LINUX_MMAPPED (USB with padded
Linux header), capture size 65535 bytes
7983 packets captured
7983 packets received by filter
0 packets dropped by kernel


There was no activity until I unplugged and replugged the USB cable, then it took off…
But when I open the PCAP file in Wireshark the traffic is all control stuff, not the user data that I can read with <cat /dev/ttyUSB0>:
URB INTERRUPT…
URB BULK…
SET_FEATURE…
GET_FEATURE…

Doing the same with tshark gives a similar result:

spectre:~ # tshark -i usbmon0 > /Downloads/tshark.txt
51   4.284002         host -> 1.0          USBHUB 64 CLEAR_FEATURE Request
[Port 2: C_PORT_RESET]
52   4.284008          1.0 -> host         USB 64 URB_CONTROL out
53   4.355995         host -> 8.0          USB 64 GET DESCRIPTOR Request DEVICE
54   4.356147          8.0 -> host         USB 82 GET DESCRIPTOR Response DEVICE
55   4.356158         host -> 8.0          USB 64 GET DESCRIPTOR Request DEVICE QUALIFIER
56   4.356278          8.0 -> host         USB 64 GET DESCRIPTOR Response DEVICE QUALIFIER[Malformed Packet]

(And, in answer to your final question, the answer is …

I'm impressed. Thanks again!

Now off to fix my user access problem…

(19 Jan ‘17, 08:04) alavarre

@alavarre

Your “answer” has been converted to a comment as that’s how this site works. Please read the FAQ for more information.

(19 Jan ‘17, 08:09) grahamb ♦

Ah! sorry, didn’t see the greyed “add a comment” button…

(19 Jan ‘17, 10:33) alavarre

@alavarre,

No worries, sometimes it’s easier to add a response as an answer to get formatting etc. correct and then convert it to a comment.

(19 Jan ‘17, 11:13) grahamb ♦

@grahmb, thanks. Curiously, now that I know to look for it, “add a comment” does not exist under Chromium Version 55.0.2883.75 (64-bit), which is why I didn’t use it before.

If I open this link under Firefox it does!!!

I’ll start a new thread on this topic.

In the meantime:

We’re closing this thread as <solved> based on Guy Harris’ excellent explanation of the libcap bug and Wireshark limitations. We understand that usbmon0 is a virtual device comprising all the usbmonN devices. We can see them all as both user and root.

Two questions remain, better pursued as their own threads that I’ll start shortly:

1. I can sniff usbmonN, but all I see is control language packets. What must I do to see user packets that are visible in cat /dev/ttyUSB0? what must I do to see EtherNet packets that I am certain exist on the same connection?


    

  1. I can see usbmonN as both user and root. I have followed Sniffing with Wireshark as a Non-Root User (and more, including # chgrp wireshark /dev/usbmon* )  but Wireshark does not see usbmonN when started as user, only when started as root. sudo wireshark returns
Unable to init server: Could not connect: Connection refused
(wireshark:6215): Gtk-WARNING **: cannot open display
(19 Jan ‘17, 14:05) alavarre

We’re leaving this thread as Solved based on your contributions and Guy Harris’ excellent explanation of the libpcap bug and Wireshark limitations. We understand that usbmon0 is a virtual device comprising all the usbmonN devices. We can see them all as both user and root.

In short: • Wireshark cannot show usbmon0 as either user or root:

==============

• tshark is a command line version of Wireshark

• usbmon0 is a virtual device comprising the full lot of usbmonN. It does not show up as a consequence of a libpcap bug, the correction of which has not yet been propagated to libpcap1 under openSUSE Leap 42.1

• As a consequence one must use command line programs (tshark, tcpdump) with -i usbmon0 to see the output of usbmon0

Other questions remain that I shall address separately.

Thank you again to all. It has been a valuable learning experience.

Kind regards, Andy

This answers my question.

(19 Jan ‘17, 14:26) alavarre

@alavarre,

I’ve again converted your “answer” to a comment. The answer for the question was that provided by @Guy Harris, to which your comment has been appended.

If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.

(20 Jan ‘17, 02:52) grahamb ♦
showing 5 of 7 show 2 more comments