On Mon, Oct 25, 2021 at 4:57 PM Kennedy, Smith (Wireless & IPP Standards) via Wireshark-dev <wireshark-dev@wireshark.org> wrote: > The "Universal Serial Bus Common Class Specification" > (https://usb.org/sites/default/files/usbccs10.pdf) discusses matching > "drivers" to devices based on the device's or interface's class, subclass and > protocol. I would suggest that, for USB, dissector matching for USB could > adopt elements of this methodology to make it easier or more clear how to add > support for new subclasses or protocols under a particular class.
Wireshark USB dissector already does that. The major issue with current Wireshark implementation is that it really works with only one configuration. Hopefully, very few devices use multiple configurations. > I don't know if that maps to needing a "heuristic" dissector. I just wanted > to point out that the USB interface descriptor provides values for class / > subclass / protocol, so "protocol" in this context doesn't have to mean "look > at the traffic and guess what protocol it is" - it can be identified in a > more deterministic way than that. But I understand that, since Wireshark is > monitoring traffic, not acting as the USB Host, its matching will be > "passive" and only apply to dissector selection. The heuristic should not be the main USB traffic detection method IMHO. The main thing is that people don't necessarily understand that capturing full enumeration sequence (aka starting capture before plugging in the device) will give you much better dissection in multiple cases. Wireshark currently supports only few USB protocols now, so this is not common knowledge yet. Recent libpcap versions automatically request device and configuration descriptors on capture start (easier version request only device descriptor). ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe