Created attachment 14635
pcap with minimal pcap for each issue
Build Information:
Wireshark 2.0.3
Copyright 1998-2016 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 3.20.3, with Cairo 1.14.6, with Pango 1.40.1, with
libpcap, with POSIX capabilities (Linux), with libnl 3, with libz 1.2.8, with
GLib 2.48.0, without SMI, with c-ares 1.11.0, with Lua 5.2, with GnuTLS 3.4.11,
with Gcrypt 1.7.0, with MIT Kerberos, with GeoIP, with PortAudio V19-devel
(built Dec 6 2015 12:27:18), without AirPcap.
Running on Linux 4.5.4-1-ARCH, with locale en_US.UTF-8, with libpcap version
1.7.4, with libz 1.2.8, with GnuTLS 3.4.11, with Gcrypt 1.7.0.
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (with SSE4.2)
Built using gcc 5.3.0.
When parsing USB SET_REPORT packets Wireshark has some problems. In some cases it parses invalid values, in other cases it doesn't detect the bRequest.The first case can be seen here:URB setup[upper part:] bmRequestType: 0x21 bRequest: 128 wValue: 0x1109 wIndex: 258 (0x0102) wLength: 5120 Data Fragment: 11ff0f0b00000000000000000000000000000000[lower part:]bRequest: SET_REPORT (0x09)wValue: 0x0211wIndex: 1wLength: 200000 80 e7 5f 48 07 88 ff ff 53 02 00 04 01 00 00 00 .._H....S.......0010 cd e0 13 57 00 00 00 00 47 dc 09 00 8d ff ff ff ...W....G.......0020 14 00 00 00 14 00 00 00 21 09 11 02 01 00 14 00 ........!.......0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0040 11 ff 0f 0b 00 00 00 00 00 00 00 00 00 00 00 00 ................0050 00 00 00 00 ....From the USB 3.1 Specification (Revision 1.0, page 78 - http://www.usb.org/developers/docs/):"Control endpoints have a fixed maximum control transfer data payload size of 512 bytes and have a maximum burst size of one. These maximums apply to all data transactions during the data stage of the control transfer."Therefore a wLength of 5120 can never be the case.The relevant byte block here is "21 09 11 02 01 00 14 00". The first byte specifies the bmRequestType, the second one bRequest, the 3rd and 4th one wValue (in little endian), the 5th and 6th wIndex (le) and the 8th and 9th wLength (le).The bmRequestType is parsed correctly in the upper part.After that the very first byte of the frame is parsed as bRequest (0x80 -> 128). The rest of the values (wValue, wIndex and wLength) are parsed from after the bmRequestType, where actually the real bRequest is (byte 0x2A). Therefore everything is shifted off one by left leading to these incorrect values.Interestingly the lower values are all correct.This first bug only appears if you have a "GET DESCRIPTOR Req/Res CONFIGURATION" in your packetdump (see appended file 'incorrect-values-with-get-descriptor.pcap').If we now remove the "GET DESCRIPTOR" request and response and only export the "SET_REPORT Request" (see appended file "incorrect-values-without-get-descriptor.pcap"), we get the second issue:URB setup bmRequestType: 0x21 bRequest: 9 wValue: 0x0211 wIndex: 1 (0x0001) wLength: 20 Data Fragment: 11ff001b000000000000000000000000000000000000 40 fe e8 4f 08 88 ff ff 53 02 00 04 01 00 00 00 @..O....S.......0010 cd e0 13 57 00 00 00 00 88 a0 07 00 8d ff ff ff ...W............0020 14 00 00 00 14 00 00 00 21 09 11 02 01 00 14 00 ........!.......0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0040 11 ff 00 1b 00 00 00 00 00 00 00 00 00 00 00 00 ................0050 00 00 00 00 ....Wireshark parses all values of the URB setup correctly. But it doesn't resolve the bRequest, which should be "SET_REPORT (0x09)". Therefore it displays the packet as "URB_CONTROL out" instead of "SET_REPORT Request".
Issue 2 is not a bug: if you remove the GET DESCRIPTOR request/response, Wireshark cannot automatically identify the protocol used by this USB device and displays the raw data instead. In theory you can force the protocol to be used via the Decode As menu but it apperas that USBHID dissector does not register to this functionality. What I can do in Wireshark development tree (Wireshark 2.1.X) is to also add USBHID to Decode As menu.