[RFC] usb: mon: Increase BUFF_MAX to support modern higher-speed devices

[RFC] usb: mon: Increase BUFF_MAX to support modern higher-speed devices

[Forest Crossman]

Hello,

The usbmon binary interface currently truncates captures for large
transfers from higher-speed USB devices. This is caused by the
BUFF_MAX limit in drivers/usb/mon/mon_bin.c, which has not been
updated since the usbmon binary interface was first introduced in
2006. A single event capture is limited to one-fifth of the total
buffer size, capping URB captures at 240 KiB each.

I discovered this limitation while developing a Wireshark protocol
dissector [1], where truncated captures made it impossible for the
dissector to defragment and reassemble the protocol packets (an
example of this truncation can be seen in frame 1580 of this capture
file [2]). Others in the community have also encountered this hard
limit when working with modern devices that use transfers of several
hundred kilobytes or more [3].

The original comment for BUFF_MAX based its calculation on a saturated
480 Mbit/s bus. Applying the same logic to a USB 3.2 Gen 2×2 20 Gbit/s
bus (~2500 MB/s over a 20ms window) indicates a required buffer size
of at least 50 MB.

I propose increasing BUFF_MAX to 64 MiB. Making this change would
enable usbmon to better support capturing the USB traffic of modern
higher-speed devices, enabling users and developers to debug and
reverse engineer their USB devices while running unmodified distro
kernels. This change would not affect the default buffer size, as a
larger buffer is only allocated when explicitly requested via the
MON_IOCT_RING_SIZE ioctl.

This proposal follows the same rationale as the original calculation,
but with updates for modern hardware.

I would appreciate any feedback on this approach before I prepare a patch.

Thank you,
Forest

[1]: https://github.com/cyrozap/mct-usb-display-adapter-re/tree/master/wireshark
[2]: https://github.com/cyrozap/mct-usb-display-adapter-re/blob/aad88e9fb80603ebf45fcd3ecb57640c3970986b/captures/trace-JCD543-20220514T1925-win10-plug-in-dongle-with-hdmi-disconnected-then-connect-1080p-edid.pcapng.gz
[3]: https://web.archive.org/web/20240618163716/https://ask.wireshark.org/question/23535/how-to-increase-capture-length-framecap_len-when-using-wireshark-for-usb-sniffing-on-ubuntu/

Re: [RFC] usb: mon: Increase BUFF_MAX to support modern higher-speed devices

[Greg KH]

On Mon, Sep 08, 2025 at 11:50:00PM -0500, Forest Crossman wrote:
> Hello,
> 
> The usbmon binary interface currently truncates captures for large
> transfers from higher-speed USB devices. This is caused by the
> BUFF_MAX limit in drivers/usb/mon/mon_bin.c, which has not been
> updated since the usbmon binary interface was first introduced in
> 2006. A single event capture is limited to one-fifth of the total
> buffer size, capping URB captures at 240 KiB each.
> 
> I discovered this limitation while developing a Wireshark protocol
> dissector [1], where truncated captures made it impossible for the
> dissector to defragment and reassemble the protocol packets (an
> example of this truncation can be seen in frame 1580 of this capture
> file [2]). Others in the community have also encountered this hard
> limit when working with modern devices that use transfers of several
> hundred kilobytes or more [3].
> 
> The original comment for BUFF_MAX based its calculation on a saturated
> 480 Mbit/s bus. Applying the same logic to a USB 3.2 Gen 2×2 20 Gbit/s
> bus (~2500 MB/s over a 20ms window) indicates a required buffer size
> of at least 50 MB.
> 
> I propose increasing BUFF_MAX to 64 MiB. Making this change would
> enable usbmon to better support capturing the USB traffic of modern
> higher-speed devices, enabling users and developers to debug and
> reverse engineer their USB devices while running unmodified distro
> kernels. This change would not affect the default buffer size, as a
> larger buffer is only allocated when explicitly requested via the
> MON_IOCT_RING_SIZE ioctl.
> 
> This proposal follows the same rationale as the original calculation,
> but with updates for modern hardware.
> 
> I would appreciate any feedback on this approach before I prepare a patch.

I would suggest trying it out and seeing if it will work properly.  CPU
speeds are faster now, so a larger buffer will probably be just fine,
but I think the original goal here was that the majority of the "real"
information was in the beginning of the urb (protocol stuff, not
data), so the end of the urb wasn't all that necessary to see if the
buffer was too big.  And, as you point out, 480 Mbit was the speeds
then, we didn't think that USB would ever be boosted to go this fast :)

thanks,

greg k-h