ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 4401] New: USB URB_ISOCHRONOUS Packet "Application Data" i

Date: Mon, 18 Jan 2010 17:46:48 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4401

           Summary: USB URB_ISOCHRONOUS Packet "Application Data" is
                    displayed/captured wrong
           Product: Wireshark
           Version: 1.2.2
          Platform: All
        OS/Version: Ubuntu
            Status: NEW
          Severity: Major
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: gregor.anich@xxxxxx


Build Information:
Version 1.2.2

Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
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 with GTK+ 2.18.3, with GLib 2.22.2, with libpcap 1.0.0, with libz
1.2.3.3, with POSIX capabilities (Linux), with libpcre 7.8, with SMI 0.4.8,
with
c-ares 1.6.0, with Lua 5.1, with GnuTLS 2.8.3, with Gcrypt 1.4.4, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 20 2009 13:28:51),
without AirPcap.

Running on Linux 2.6.31-17-generic, with libpcap version 1.0.0, GnuTLS 2.8.3,
Gcrypt 1.4.4.

Built using gcc 4.4.1.

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
Kernel: 2.6.31-17-generic i686 (Ubuntu)

When capturing data from the USB bus on linux the data payload displayed or
captured for USB URB_ISOCHRONOUS packets is wrong.
It seems like the binary data coming from the usbmon module of the kernel is
interpreted wrongly.
It doesn't match the output of the usbmon program
(http://people.redhat.com/zaitcev/linux/) - here's an example:


Wireshark:

19    0.000037    host    5.2    USB    URB_ISOCHRONOUS

Application Data:
0000   01 00 00 00 00 00 00 00 02 00 00 00 08 00 00 00  ................
0010   ee ff ff ff 00 00 00 00 1e 00 00 00 00 00 00 00  ................
0020   ee ff ff ff 1e 00 00 00 24 00 00 00 00 00 00 00  ........$.......
0030   ee ff ff ff 42 00 00 00 1e 00 00 00 00 00 00 00  ....B...........
0040   ee ff ff ff 60 00 00 00 24 00 00 00 00 00 00 00  ....`...$.......
0050   ee ff ff ff 84 00 00 00 1e 00 00 00 00 00 00 00  ................
0060   ee ff ff ff a2 00 00 00 24 00 00 00 00 00 00 00  ........$.......
0070   ee ff ff ff c6 00 00 00 1e 00 00 00 00 00 00 00  ................
0080   ee ff ff ff e4 00 00 00 24 00 00 00 00 00 00 00  ........$.......
0090   d6 8e 0e 00 00 00 c0 77 20 00 00 00 3a b8 31 00  .......w ...:.1.
00a0   00 00 c4 f6 41 00 00 00 18 df 50 00 00 00 e0 23  ....A.....P....#
00b0   5e 00 00 00 44 80 69 00 00 00 56 b9 72 00 00 00  ^...D.i...V.r...
00c0   3c 9f 79 00 00 00 2d 0e 7e 00 00 00 29 ef 7f 00  <.y...-.~...)...
00d0   00 00 70 38 7f 00 00 00 b8 ed 7b 00 00 00 13 20  ..p8......{.... 
00e0   76 00 00 00 9c ed 6d 00 00 00 dc 80 63 00 00 00  v.....m.....c...
00f0   e5 0f 57 00 00 00 45 db 48 00 00 00 ac 2c 39 00  ..W...E.H....,9.
0100   00 00 76 55 28 00 00 00                          ..vU(...


usbmon-5.4:

f6a27900 0.577452 S Zo:1:005:2 -:1:0 8 -18:0:30 -18:30:36 -18:66:30 -18:96:36
-18:132:30 -18:162:36 -18:198:30 -18:228:36 264 = d68e0e00 0000c077 20000000
3ab83100 0000c4f6 41000000 18df5000 0000e023 5e000000 44806900 000056b9
72000000 3c9f7900 00002d0e 7e000000 29ef7f00 00007038 7f000000 b8ed7b00
00001320 76000000 9ced6d00 0000dc80 63000000 e50f5700 000045db 48000000
ac2c3900 00007655 28000000 02ad1600 0000ea8e 04000000 2d59f200 0000426a
e0000000 321fcf00 0000b5d1 be000000 5ed6af00 0000e77a a2000000 9a049700
0000efae 8d000000 52aa8600 00002e1b 82000000 27198000 0000aaae 80000000
aed88300 0000ca86 89000000 859b9100 0000f3ec 9b000000 8e45a800 00004765
b6000000 da02c600 000043cd d6000000 676de800 0000d587 fa000000


As can be seen, the true "Application data" (Packet/transaction content) starts
with d68e0e00 and not 01000000!
The first 16 bytes in the "Application data" might be the last 16 bytes of
struct mon_bin_hdr from linux-2.6.32/drivers/usb/mon/mon_bin.c line 84
The rows starting with eeffffff look like struct mon_bin_isodesc from
linux-2.6.32/drivers/usb/mon/mon_bin.c line 116

Since I don't know anything about the architecture of Wireshark, I don't know
where this bug is. I suspect the bug is in the USB dissector,
wireshark/trunk-1.2/epan/dissectors/packet-usb.c, function
dissect_linux_usb_common.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.