--da4uJneut+ArUgXk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 28, 2006 at 06:30:47PM -0700, Bill Studenmund wrote:
> On Fri, Apr 28, 2006 at 03:58:14PM -0700, Bill Studenmund wrote:
> > On Fri, Apr 28, 2006 at 11:01:43AM -0600, John R. Shannon wrote:
> > >=20
> > > I've captured the packets using:
> > >=20
> > > tcpdump -s 1600 -w logincapture -ni eth0 host 10.1.1.3
> > >=20
> > > while executing:
> > >=20
> > > iscsiadm -m node --record=3Db24590 --login
> > >=20
> > > How should I submit the binary files?
> >=20
> > Upload to ftp.n.o?
>=20
> Ok, I saw the upload you sent to the open-iscsi list.
>=20
> Something's messed up in the report luns output.
>=20
> It's _supposed_ to be:
>=20
> Bytes  0 ->  3    contain the length in NBO of data after the header
> Bytes  4 ->  7    Reserved, should be zero.
>=20
> Bytes  8 -> 15	First LUN (8 bytes)
> Bytes 16 -> 31	Second LUN (8 bytes), and so on.
>=20
> In the trace on the open-iscsi list, as best I can tell these data are in=
=20
> packet 17.
>=20
> Packet 17, however, contains text.

Oh, I forgot. There's more.

As best I can tell, the target returns 4k of LUN info, which is what was=20
requested. However this is wrong.

The SCSI layer is only supposed to generate as much data as it has. Since=
=20
it looks like the code wants to support 8 LUNs, that would be 8 bytes of=20
header + 8 * (8 bytes / LUN) =3D 72 bytes of data.

The iSCSI layer should only send 72 bytes, then flag an underrun for the=20
difference between 4k and 72 bytes.

For most commands, like READ or WRITE, the amount of data iSCSI wants to=20
transfer will match the amount that SCSI wants to generate.

For things like INQUIRY and REPORT_LUNS and such, however, it'll be quite=
=20
common for the amount of data to differ.

Note: there really are three lengths. There's the amount of data iSCSI=20
wants to transfer, then there's the amount of data the SCSI CDB wants to=20
transfer, and finally there's the amount of real data.

For inquiry data, there's an amount generated. For this target, it seems=20
to be a total of 37 bytes (which sounds like it's off by 1). This is the=20
"real data" I mention above.

In packet 7, the initiator (well Linux SCSI layer) requests 36 bytes of=20
inquiry data. We generate 37, but send 36. Since both the CDB and the=20
iSCSI transfer lengths are the same, there'd be no overrun or underrun.=20
You just get the first 36 of 37 bytes.

The initiator then notices that it missed some data, and sends a second=20
request, packet 12, with a SCSI and iSCSI transfer length of 37.

Windows, however, will often ask for 255 bytes of data and look at what it=
=20
got. You're only supposed to send the "real data", and no more. :-)

Take care,

Bill

--da4uJneut+ArUgXk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEUsU2Wz+3JHUci9cRAvIxAKCQcVWSWejS8/VAkHrLOmjvwwbfiACgjGsd
IRnvLpFR/7ICg9JtN0j59WY=
=5f33
-----END PGP SIGNATURE-----

--da4uJneut+ArUgXk--