[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.