| Bug ID |
9071
|
| Summary |
Incoherent Request / Response Identification of SCSI traffic
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.10.1
|
| Hardware |
x86
|
| OS |
Windows 7
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Version 1.10.1 (SVN Rev 50926 from /trunk-1.10)
Copyright 1998-2013 Gerald Combs <[email protected]> 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.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with
PortAudio V19-devel (built Jul 26 2013), 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 2.12.18, Gcrypt 1.4.6, without AirPcap.
Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz, with 8125MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
--
The SCSI CDB, SCSI Response, and SCSI Payload layers include references to the
Frame # containing both Request and Response. I'm skeptical of the result,
because Wireshark sometimes claims that the Response occurs prior to the
Request.
In the sample trace, see Frame #58192. Wireshark claims that the Request for
this Response lives in Frame #71841. I'm skeptical that the Response appeared
after the Request.
In fact, by filtering on "scsi.time > 1", I find a handful of such examples.
How do we link Requests & Responses? I would guess that we use
InitiatorTaskTags plus CmdSN and ExpStatSN ... in the examples above, the
purported Response packets have iSCSI Sequence Number fields set to all zeros.
Interestingly, this trace was extracted from a larger one ... and in that
larger trace, the purported Request/Response pairs are /different/.
You are receiving this mail because:
- You are watching all bug changes.