Nigel, you hit the problem on the head. Once I correctly set the
residual value for a non-error case things started to work. There was
also an issue in the MODE_SENSE where I wasn't setting a couple of
fields correctly, but they were extremely easy to track down once the
connection was up and running. I still need to complete some testing,
but I'll work at getting these changes back into Solaris so they'll
be available ASAP.
On Jan 14, 2007, at 10:20 AM, Rick McNeal wrote:
You might just be onto something here.
When sending the certain SCSI commands the amount of data to be
returned is unknown. The INQUIRY command falls into this category.
The initiator tries to request more data than it really expects to
get. When this condition occurs the target is supposed to return
the data *and* a separate SCSI Response PDU with a residual count.
The target isn't currently doing this and I suspect this to be the
problem. It would appear that the Windows Initiator is now checking
for this condition and dropping the connection. The previous
version of the Initiator did not and therefore worked.
I'm working on this today, Sunday, and expect to have results by
this afternoon. I'll let you know and thanks again for digging
through this stuff.
On Jan 13, 2007, at 9:06 PM, Nigel Smith wrote:
Rick, the following may (or may not) be a clue to what's going wrong.
(It may also be something you have already fixed, as I am using
snv_54, and I know you have moved the code on since then.)
I'm now running the version of Microsoft's iscsi initiator that
supports debug logging.
In the output windows of 'DebugView', the message I keep seeing is:
"0: Not enough data. Expected 255, Given 144"
I note that the last packet sent by your Target back to the
initiator (just before the [RST,ACK] from the initiator) has a TCP
data length of 144.
That last packet is a continuation packet, and is the second half
of the "Data In" packet, which is itself a response to the second
"Inquiry LUN" packet (with EVPD=1) from the initiator.
The "Data In" packet specifies a DataSegmentLength of 0x90, which
is 144 in decimal.
So why does Microsoft say it expects 255 ?
Well that second "inquiry LUN" packet from the initiator has a
field - ExpectedDataTransferLength = 0xFF. Of course, I'm just
guessing.
The actual size of the active data in that last continuation
packets looks quite small, like about 6 bytes, with the rest just
0x00 padding.
And I note that RFC3720 say's:
"10.2.1.6. DataSegmentLength
This is the data segment payload length in bytes (excluding
padding)."
I don't fully understand this iScsi protocol, so like I said at
the beginning, this is just maybe a clue.
Ok, this is just my latest idea, and you will probably blow it out
the water, like the others, but I think it's worth a try.
Thanks
Nigel
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
----
Rick McNeal
"If ignorance is bliss, this lesson would appear to be a deliberate
attempt on your part to deprive me of happiness, the pursuit of
which is my unalienable right according to the Declaration of
Independence. I therefore assert my patriotic prerogative not to
know this material. I'll be out on the playground." -- Calvin
----
Rick McNeal
"If ignorance is bliss, this lesson would appear to be a deliberate
attempt on your part to deprive me of happiness, the pursuit of which
is my unalienable right according to the Declaration of
Independence. I therefore assert my patriotic prerogative not to
know this material. I'll be out on the playground." -- Calvin
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
