On Oct 22, 2021, at 10:36 PM, Guy Harris <ghar...@sonic.net<mailto:ghar...@sonic.net>> wrote:
On Oct 22, 2021, at 6:06 PM, Aidan MacDonald via Wireshark-dev <wireshark-dev@wireshark.org<mailto:wireshark-dev@wireshark.org>> wrote: > Second, the hooks provided by the generic USB dissector seemingly aren't a > good fit. Basically, it seems to use only the interface class to decide what > sub-dissector to call, but UASP uses the mass storage class like the existing > Bulk-Only transport dissector. So that dissector is essentially sitting in > the way and preventing me from hooking in UASP. (Or at least I think so. > Currently I'm just commenting it out the conflicting hooks during testing.) > > I need to look at the interface protocol to determine if the traffic is UASP > or not. I think the simplest way to do this is adding a shim dissector for > mass storage class which invokes either the BOT or UASP dissector depending > on the interface protocol (if known). Does that sound like a good approach? That seems to make sense. The current mass storage class dissector just registers in the "usb.bulk" and "usb.control" dissector tables based on the interface class. *However*, there's also a *heuristic* dissector registered in the "usb.bulk" heuristic dissector table, and *that* looks for what appears to be a signature of Bulk-Only Transport packets. If so, then the *heuristic* dissector should directly call the Bulk-Only Transport dissector. I don't know whether there's a heuristic that can recognize UASP traffic; if so, you'll have to write a separate heuristic dissector for that. 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. 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. (I haven't used USB dissection in Wireshark yet, but if it had a way to trace the device and interface selection process between the Host and Peripheral, that would be very helpful for debugging certain classes of problems!)
___________________________________________________________________________ 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
