Wireshark-bugs: [Wireshark-bugs] [Bug 8803] New: iSCSI: Data-In PDUs are not reassembled if ther
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 14 Jun 2013 23:48:13 +0000
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 bugzilla-admin@wireshark.org
Reporter uce@rjgodoy.com.ar 

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.