[Bug 281790] Behavior of usbdump(8) counterintuitively under-lists frames by default

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 01 Oct 2024 08:48:39 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281790

            Bug ID: 281790
           Summary: Behavior of usbdump(8) counterintuitively under-lists
                    frames by default
           Product: Base System
           Version: 13.3-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: usb
          Assignee: usb@FreeBSD.org
          Reporter: mhjacobson@me.com

Running something like this:

# usbdump -d 3.2 -v

Results in output like this (hexdumps elided for clarity):

04:45:09.159790 usbus3.2 SUBM-ISOC-EP=00000081,SPD=HIGH,NFR=32,SLEN=0,IVAL=0
 frame[0] READ 3060 bytes
 frame[1] READ 3060 bytes
 frame[2] READ 3060 bytes
 frame[3] READ 3060 bytes
 frame[4] READ 3060 bytes
 frame[5] READ 3060 bytes
 frame[6] READ 3060 bytes
 frame[7] READ 3060 bytes
04:45:09.159847 usbus3.2
DONE-ISOC-EP=00000081,SPD=HIGH,NFR=32,SLEN=92820,IVAL=0,ERR=0
 frame[0] READ 3060 bytes

Where are the rest of the frames?  3060 is not equal to 92820.

It turns out that this is a result of the default value of `snapshot` in
`usbdump.c`.  By default, usbdump only captures 192 bytes of each "packet" from
BPF.  This means that it misses lots of frames, producing this confusing
output.

Adding `-s0` to the command restores the missing information, but the default
behavior is very confusing.

-- 
You are receiving this mail because:
You are the assignee for the bug.