Ask Your Question
0

How to increase capture length ("frame.cap_len") when using Wireshark for USB sniffing on Ubuntu?

asked 2021-07-12 13:52:36 +0000

AlexDoe gravatar image

I'm using Wireshark 3.2.3 and usbmon for capturing USB traffic on Ubuntu 20.04. All the required tools and packages were installed just a week ago, so they ought to be of recent versions.

The problem looks like this in the captured log (after exporting it as JSON):

"frame.len": "524352",
"frame.cap_len": "245824",

Only half of the actual data was captured by Wireshark. Since the payload can only be decoded as a single continuous stream, this makes it entirely impossible to actually decode and analyze anything from this point forward.

How can I increase this limit and capture ALL the payload?

edit retag flag offensive close merge delete

Comments

Will it work to capture to a file then open it in Wireshark for analysis?
Try making a capture with tcpdump or dumpcap, specifying a snaplen with the -s option.

If that works, a possible workaround to specifying a large snaplen is in issue 15389.

Chuckc gravatar imageChuckc ( 2021-07-12 18:12:06 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2021-07-13 08:58:07 +0000

Guy Harris gravatar image

I'm using Wireshark 3.2.3 and usbmon for capturing USB traffic on Ubuntu 20.04.

Presumably you mean that you're capturing with Wireshark and using the usbmon devices.

If so, then this is a limit wired into the Linux kernel. To quote a comment in the libpcap code for usbmon:

    /*
     * A packet from binary usbmon has:   
     * 
     *  1) a fixed-length header, of size header_size;
     *  2) descriptors, for isochronous transfers;
     *  3) the payload.
     *
     * The kernel buffer has a size, defaulting to 300KB, with a
     * minimum of 8KB and a maximum of 1200KB.  The size is set with
     * the MON_IOCT_RING_SIZE ioctl; the size passed in is rounded up
     * to a page size.
     *
     * No more than {buffer size}/5 bytes worth of payload is saved.
     * Therefore, if we subtract the fixed-length size from the   
     * snapshot length, we have the biggest payload we want (we
     * don't worry about the descriptors - if we have descriptors,
     * we'll just discard the last bit of the payload to get it
     * to fit).  We multiply that result by 5 and set the buffer
     * size to that value.
     */

So if {buffer_size} is the maximum value allowed by the kernel, namely 1200 KB (KiB, really, i.e. 1200*1024), then the "No more than ... worth of payload is saved" value is 245760. 245824 is that plus the size of the header prepended to the data, which is 64 bytes.

Fixing this would first require that BUFF_MAX be increase in the usbmon driver in the Linux kernel. Then libpcap would have to be modified to handle the larger maximum for USB capturing on Linux, and then Wireshark would have to be modified to handle that as well.

edit flag offensive delete link more

Comments

Thank you for the explanation, that's sad. Is there an alternative to usbmon that would let me capture the complete data (524352 bytes, I assume)? Also, I'm a bit confused here: isn't the USB packet size 512 bytes for USB 2.0 and 1024 bytes for USB 3.0? How is it possible to get a single chunk of data 512 KiB in length, rather than 1024 packets of 512 bytes or 512 packets of 1024 bytes?

AlexDoe gravatar imageAlexDoe ( 2021-07-13 09:14:16 +0000 )edit

Is there an alternative to usbmon that would let me capture the complete data (524352 bytes, I assume)?

None that I know of, other than "ask the Linux kernel people to change usbmon to let you capture the full packet".

Also, I'm a bit confused here: isn't the USB packet size 512 bytes for USB 2.0 and 1024 bytes for USB 3.0?

The ATM cell size is 53 bytes, but that doesn't mean an ATM capture file has nothing but 53-byte cells. Captures are not necessarily done on the "raw" link layer, and some level of assembly may already have been done at the time the packets are presented to the capturing host.

Guy Harris gravatar imageGuy Harris ( 2021-07-13 21:00:12 +0000 )edit

Understood, thank you once again for the info (can't upvote the answer, sorry, not enough reputation).

AlexDoe gravatar imageAlexDoe ( 2021-07-13 21:38:07 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-07-12 13:51:47 +0000

Seen: 1,238 times

Last updated: Jul 13 '21