https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15842
--- Comment #5 from Tomasz Mon <deso...@gmail.com> ---
It looks that the USBPcap dissector did not really change much since I
implemented it back in 2013 (Bug 8503). Thus it is possible to change
(described below) USBPcap format in a way that would make old versions of
Wireshark handling the data from a new proposed USBPcap correctly (while
remaining the oddity for old versions). This is especially appealing to me as
it would make the Windows XP with Wireshark 1.10 work as it was originally
intended.
The MBIM hack would be affected, but every solution I can think of breaks
something. The latest idea seems to break the least amount of things.
The new proposed USBPcap change is to:
1. Make USBPCAP_CONTROL_STAGE_SETUP to contain SETUP and DATA OUT. If you want
to differentiate between old and proposed new USBPcap version, you check the
bmRequestType for Host to device, and wLength > 0 -> if the
USBPCAP_CONTROL_STAGE_SETUP has 8 bytes of data, then it is the old USBPcap, if
it has 8 + wLength, then it is proposed new USBPcap. What's suprising is that
all versions of Wireshark will correctly handle the proposed new USBPcap
meaning of USBPCAP_CONTROL_STAGE_SETUP (with the exception of the MBIM
hack...).
2. Do not record USBPCAP_CONTROL_STAGE_STATUS at all. It is not handled
correctly in Wireshark anyway (it wrongly considers vendor request codes to be
standard request codes - see USBPcap capture attached to bug 11743). I'll
submit a patch to Wireshark making this a bit less confusing (but it only will
affect future Wireshark releases).
3. Include USBPCAP_CONTROL_STAGE_DATA with 0 bytes payload (the URB status code
is bringing value here) for CONTROL OUT requests, and keep the existing
USBPCAP_CONTROL_STAGE_DATA for CONTROL IN requests. This would result in
subdissectors marking description column the same way as they do for usbmon
captures.
--
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
