[Bug 281790] Behavior of usbdump(8) counterintuitively under-lists frames by default
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.