Wireshark-bugs: [Wireshark-bugs] [Bug 3628] A Generic "Anything-over-USB" Dissector?

Date: Wed, 12 Jun 2013 12:24:04 +0000

changed bug 3628

What Removed Added
CC   [email protected]

Comment # 2 on bug 3628 from
Heh, I completely forgot about this bug report.

Whilst I was probably thinking of exposing something via the UI (probably as a
tab on the existing "Decode As..." dialogue, or the "Preferences" one), I'll
agree that save for adding an endpoint table (to specify payload types for
bulk/interrupt/isochronous payloads + vendors/product IDs, and for customising
descriptors?), the core infrastructure for implementing such a thing is pretty
much in place. (Thanks!)

I suspect that the folks working on the PTP-over-USB dissector were going to
use it (or at least they encouraged plumbing in a VID/PID table generator), and
I have a feeling that it might be a good idea to update the Ethernet-over-USB
"support" (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4819) to use it
for restricting Ethernet dissection to VID/PID pairs, to reduce false
positives.

If I ever get around to reviving the Apple USBMUX, or USB/ENCM bugs (I don't
know how likely that will be), it might work better than the heuristics.

Should we close this bug?

(In reply to comment #1)
> I hope there is no need to dissector, because we can use "DecodeBy" feature.
> In USB dissector there is several tables which can be used to choose
> dissector. For example: usb.device, usb.protocol, usb.product. I guess there
> is need to add "endpoint" table(s) too and that should be all.
> 
> Currently only "hci_usb" dissector use it power. In my opinion other
> dissectors like USB HID, USB HUB, etc. can be updated to support those
> tables. For now those dissectors crashes when I try to do that, because they
> based only on conversation/transaction (not required in new tables use
> cases).
> 
> My cases:
> usb.device - decode by BusID and DeviceAddress
> usb.protocol - decode by class/subclass and protocol fields
> usb.product - decode by ProductID and VendorID
> 
> So there is nothing about "multidevice" that use endpoint to determine
> service. Let me know if I am wrong: endpoint is last place when we can
> determine payload type? (please ignore heuristics) So usb.device need also
> endpoint(s) to be set?


You are receiving this mail because:
  • You are the assignee for the bug.
  • You are watching all bug changes.