Wireshark-bugs: [Wireshark-bugs] [Bug 11072] New: request-response cross-reference in USB URB pa
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sat, 21 Mar 2015 10:10:57 +0000
Bug ID 11072
Summary request-response cross-reference in USB URB packets incorrect
Product Wireshark
Version 1.12.4
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Minor
Priority Low
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter sindelka@marconi.ttc.cz 

Created attachment 13522 [details]
an example pcap file documenting the bug

Build Information:
Version 1.12.4 (v1.12.4-0-gb4861da from master-1.12)

Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> 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 (64-bit) with GTK+ 2.24.23, with Cairo 1.10.2, with Pango 1.34.0, with
GLib 2.38.0, with WinPcap (4_1_3), with libz 1.2.5, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, without Python, with GnuTLS 3.2.15, with Gcrypt 1.6.2,
without Kerberos, with GeoIP, with PortAudio V19-devel (built Mar  4 2015),
with
AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 3.2.15, Gcrypt 1.6.2, without AirPcap.
       Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, with 8141MB of physical
memory.
--
Hello,

the wireshark-created link to corresponding isochronous transfer packet in
display of dissected packet probably ignores the "IRP ID" field; instead, the
direct neighbour by time is pointed to (last request before the response, first
response after the request).

In the attached example, no link to response is displayed in the first 7
packets (requests); in packet 8 (request), the link is present but points to
the immediately following response (packet 9) which is actually a response to
packet 1. The same happens in reverse direction, the link to request in packet
9 points to packet 8 while it should point to packet 1.

Thank you
Pavel

You are receiving this mail because:
  • You are watching all bug changes.