https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14587

            Bug ID: 14587
           Summary: Incorrect parsing of USB CDC packets.
           Product: Wireshark
           Version: 2.4.4
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: Low
         Component: Dissection engine (libwireshark)
          Assignee: bugzilla-ad...@wireshark.org
          Reporter: 3ld3rm4l4...@gmail.com
  Target Milestone: ---

Created attachment 16249
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=16249&action=edit
Capture with malformed and correct packets

Build Information:
Wireshark 2.4.4 (Git v2.4.4 packaged as 2.4.4-1~16.04.0)

Copyright 1998-2018 Gerald Combs <ger...@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 Qt 5.5.1, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.48.2, with zlib 1.2.8, with SMI 0.4.8, with c-ares
1.10.0, with Lua 5.2.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with MIT
Kerberos, with GeoIP, with nghttp2 1.7.1, with LZ4, with Snappy, with libxml2
2.9.3, with QtMultimedia, without AirPcap, with SBC, with SpanDSP.

Running on Linux 4.4.0-116-generic, with Intel(R) Core(TM) i7-6820HQ CPU @
2.70GHz (with SSE4.2), with 31853 MB of physical memory, with locale
en_US.UTF-8, with libpcap version 1.7.4, with GnuTLS 3.4.10, with Gcrypt 1.6.5,
with zlib 1.2.8.

Built using gcc 5.4.0 20160609.

--
I'm experiencing something confusing. I'm getting Malformed Packets on the log
window but they are perfectly fine. These supposedly malformed packets reach
the device just fine and the device responds fine as well, so there is nothing
wrong with the packets. I'm sniffing a very simple CDC device and I'm sending a
0x32, 0x31, 0x0a from the host terminal.

For these tests, you need to filter as "usb.device_address == 112"

I'm getting the malformed packets if I start a session and the plug my device.
But if the device is already plugged in and I restart the session I no longer
get the malformed packets. Everything seems to work just fine.

The file "malformedPackets112.pcapng" contains the malformed captures and the
file "normalPackets112.pcapng" contains the correct packet parsing.

I noticed some discrepancies on how Wireshark report the packets on both
scenarios. When the packet is reported as malformed, I noticed that the
Protocols in frame field contains:

[Protocols in frame: usb:usb:com:eth]


But when it works fine then this same field contains:

[Protocols in frame: usb]


Additionally, I noticed that further down the field bInterfaceClass field
contain the following when the packet is supposedly malformed:

[bInterfaceClass: CDC-Data (0x0a)]


And contains the following when the packets are reported fine:

[bInterfaceClass: Unknown (0xffff)]


Here is strange because it seems that the correct contents of this field, when
the packet is not reported as malformed, should be CDC-Data, but I guess that
is part of the problem.

If I compare the bytes in the packet window I can see that everything matches
perfectly, (with exception of URB id, URB sec, and URB usec obviously) and even
the 0x32, 0x31, 0x0a sent from the host are there in both cases.

Finally, the response from my device is correct but wireshark parse it wrong.
The response from the device is: 0x0a, 0x3a, 0x56, 0x32, 0x2e, 0x34, 0x2e,
0x31, 0x30, 0x35, 0x0a (ASCII <0x06>:V2.1.4.105<0x06>) and I can see those
bytes in the packet but the wireshark capture window shows that the source is
2e:34:2e:31:30:35 wich coincides with the last part of the correct payload but
it is not the source address.

On the correct capture file you can see that it contains "Leftover Capture
Data: 063a56322e312e342e3130350a" which is correct.

-- 
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

Reply via email to