Date: Tue, 01 Oct 2024 08:48:39 +0000 From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [Bug 281790] Behavior of usbdump(8) counterintuitively under-lists frames by default Message-ID: <bug-281790-19105@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-281790-19105>