ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 10469] New: iscsi Read Capacity (16) packet parsing

Date: Tue, 16 Sep 2014 07:17:52 +0000
Bug ID 10469
Summary iscsi Read Capacity (16) packet parsing
Product Wireshark
Version 1.12.0
Hardware All
OS Windows 7
Status UNCONFIRMED
Severity Major
Priority Low
Component Capture file support (libwiretap)
Assignee [email protected]
Reporter [email protected]

Created attachment 13054 [details]
The archive contains the packets and corresponding screenshots

Build Information:
Version 1.12.0 (v1.12.0-0-g4fab41a from master-1.12)

Copyright 1998-2014 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 Qt 5.1.1 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.1.22, with Gcrypt 1.6.0, without Kerberos, with GeoIP, without
PortAudio, with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, without WinPcap, GnuTLS
3.1.22, Gcrypt 1.6.0, without AirPcap.
Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz, with 3799MB of physical
memory.


Built using Microsoft Visual C++ 10.0 build 40219
--
Hi there. I have been facing this issue. Please take note of the following
points and let me know in case of any doubts

1) there is a field 'Allocation Length' for SCSI Command Read Capacity (16)
carried over the iscsi protocol.This field is 32 bits long and can accept a
maximum value of 4294967295 (0xFF FF FF FF)as per the SCSI specs.

2) I have three different iscsi packets, (I have also attached them below), in
which the allocation length was set to 65535 (0xFF FF), 16777215 (0xFF FF FF)
and 16777216 (0x1 00 00 00) respectively. 

3)what i am facing is that the initial 2 packets with the length of 65535 and
16777215 are parsed correctly - the TCP packet is which carries the
corresponding iscsi packet within it is being differentiated from it (see
screenshot - 1 and 2)

4) in case of the last packet, a value as little as 1 byte more than 16777216
leads to the packet not being parsed. Wireshark is not able to differentiate
the iscsi packet from the TCP packet which carries it. You can compare the
packets as well I have attached at the bit level. The entire data is same,
except for the allocation length field values.

Please look into this bug and let me know ASAP.


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