| Bug ID |
12511
|
| Summary |
Invalid values for USB SET_REQUEST packets
|
| Product |
Wireshark
|
| Version |
2.0.3
|
| Hardware |
x86-64
|
| OS |
Linux (other)
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
GTK+ UI
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 14635 [details]
pcap with minimal pcap for each issue
Build Information:
Wireshark 2.0.3
Copyright 1998-2016 Gerald Combs <[email protected]> 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: 0x0211
wIndex: 1
wLength: 20
0000 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: 11ff001b00000000000000000000000000000000
0000 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".
You are receiving this mail because:
- You are watching all bug changes.
