Bug ID |
8803
|
Summary |
iSCSI: Data-In PDUs are not reassembled if there is Bidirectional Read Residual Underflow.
|
Classification |
Unclassified
|
Product |
Wireshark
|
Version |
SVN
|
Hardware |
x86-64
|
OS |
Windows 7
|
Status |
UNCONFIRMED
|
Severity |
Major
|
Priority |
Low
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Created attachment 10988 [details]
patch that fixes the issue for ordered sequences, and breaks dissection of
unordered sequences
Build Information:
iSCSI dissector from SVN (latest) compiled as plugin, and standard Wireshark
distribution:
Version 1.10.0 (SVN Rev 49790 from /trunk-1.10)
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 Jun 5 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) i5-3570K CPU @ 3.40GHz, with 8074MB of physical
memory.
Built using Microsoft Visual C++ 10.0 build 40219
--
When there is Bidirectional Read Residual Underflow in the Data-In buffer (i.e.
"some bytes were not transferred to the initiator out of the number of bytes
expected to be transferred", in a bidirectional operation), the SCSI layer
fails to reassemble the Data-In sequence (even if there is a single PDU in that
Sequence). From my understanding of the SCSI reassembling process
(packet-scsi.c:5618), that should happen for unidirectional Residual Underflow,
but I haven't verified if that is the case.
The actual transferred length can be computed from:
1. from the Residual Count in the SCSI Response PDU if the last Data-In PDU in
the sequence does not have the S bit set.
2. from the Residual Count in the final Data-IN PDU if it has the S bit set.
3. as Buffer Offset + DataSegmentLength on the final Data-IN PDU, if there are
several Data-In PDU, the first Buffer Offset is 0 (?), and the sequence is
ordered (as in DataPDUInOrder=Yes)
4. as the difference between the largest (Buffer Offset + DataSegmentLength)
and the smallest Buffer Offset.
The submitted patch implements methods 2 and 3, and *works for me* since all my
test cases are ordered (and I have no idea how to implement the other
approaches, nor I can test them). This patch will break dissection of unordered
sequences (even if they have no underflow condition).
Example:
SCSI Request PDU
Bidirectional Read Data Length: 0x0040000
Data-In PDU
Flags: 0x80
1... .... = F: Final PDU in sequence
.... ...0 = S: Response does not contain SCSI status
DataSegmentLength: 0x00000018
BufferOffset: 0x00000000
ResidualCount: 0x00000000 (no Residual Count because there is no Status)
SCSI Response PDU
DataSegmentLength: 0x00000000
BidiReadResidualCount: 0x0003ffe8
Flags: 0x88
.... 1... = u: Read part of bi-directional command underflowed
You are receiving this mail because:
- You are watching all bug changes.