Subject: [Ips] Question about invalid PDUs and SCSI sense data

From: William Studenmund <[email-masked]>
Date: Thu, 11 Aug 2005 19:11:56 -0700

I'm looking through some potential invalid PDU cases, and wondering 
about what would be appropriate sense data.

For all of these cases, let the invalid iSCSI PDUs relate to an 
instantiated SCSI task. As I understand it, the invalid PDU should be 
responded to with a Reject PDU (0x3F) and a Reason code of 0x09. I 
however want to also kill off the related SCSI task, and as per Note 2 
in RFC 3720 section 10.17.1, I have to report SCSI sense info.

I however don't know what appropriate sense data are for all cases. 
There are some cases mentioned in the spec in section 10.4.7, and they 
are clear. However my imagination has come up with more, and I'm not so 
sure about them. I _think_ I can find existing ASC/ASCQ values, but 
wanted input.

Case 1: Data-Out PDU received with no corresponding valid TTT. Note: I 
am implicitly assuming the target examines ITT before TTT; if it 
examined TTT before ITT, then the Data-Out PDU wouldn't match a task 
and no task would be impacted. Would Sense Key Aborted Command (0x0b), 
ASC/Q 0x4b/0x00 Data Phase Error be appropriate?

Case 2: Data-Out PDU in a write command with invalid parameters.

For a specific example, the Data-Out is for a TTT other than 
0xffffffff, the ITT matches the ITT associated with that TTT, and its 
LUN field differs from that of the command. As I understand the 
paragraph at the top of page 141, "the LUN field MUST hold a valid 
value and be consistent with whatever was specified with the command." 
Another example is Buffer Offset out of bounds for the TTT.

I haven't found a good ASC/Q. 0x49/0x00 Invalid Message Error maybe? 
Yes, it's normally a SPI thing, but it indicates an error with 
transport level messages, which is what's happening here.

Oh, hmmm... I think the Buffer Offset issue specifically could use 
0x4b/0x05 Data Offset Error. But Buffer Offset isn't the only parameter 
error that can happen.

Thoughts?

Take care,

Bill
_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Paul Koning <[email-masked]>
Date: Fri, 12 Aug 2005 09:01:46 -0400

>>>>> "William" == William Studenmund <[email-masked]> writes:

 William> I'm looking through some potential invalid PDU cases, and
 William> wondering about what would be appropriate sense data.

 William> For all of these cases, let the invalid iSCSI PDUs relate to
 William> an instantiated SCSI task. ...

How would you know that?

The way I look at invalid PDUs is that the sender is confused, so you
can't trust any of the bits in the PDU.  In particular, if the sender
doesn't know how to speak the protocol correctly, what assurance do
you have that the TTT is right?

    paul

---

From: William Studenmund <[email-masked]>
Date: Fri, 12 Aug 2005 10:28:04 -0700

>  William> an instantiated SCSI task. ...

Good question.

The target will have to look at different fields in the PDU to figure 
out where to route the PDU, and at some point enough of the fields will 
match to indicate a PDU belongs with a task. All the values (ITT, TTT, 
LUN) are supposed to match, so any time when they don't is an error 
case. Exactly where that happens is up to the target.

But I think it's perfectly reasonable for the target to get upset once 
whatever list of match criteria have been met and something else 
doesn't match.

> you have that the TTT is right?

Well, if we think the sender's that confused, why continue trying to 
talk to it? :-) So why not kill a task with this errant party. :-)

The Reject PDU explicitly states that if a SCSI task is terminated as a 
result of the Reject, SCSI sense data MUST be sent. While I agree it 
doesn't state that you MUST terminate a SCSI task, it certainly 
indicates that the idea of an iSCSI Reject leading to a SCSI task dying 
is accepted.

We already have examples in RFC 3720 where we report SCSI Sense data in 
response to iSCSI protocol confusion. Unsolicited data when it's not 
supposed to be there, too much unsolicited data, or a bad SNACK all 
have recommended Sense Data. All three of those cases are where we 
think we can (logically) tie a PDU to a task even though there was 
confusion.

So I think I agree and disagree with you. I think you're right that we 
need to make sure we think a PDU relates to a task before escalating an 
iSCSI Reject into a SCSI event, but I disagree in that I think there is 
a class of iSCSI Rejects which should also turn into SCSI events. In 
light of your question, though, I think I'll require the initiator get 
(ITT, TTT) right first. :-)

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 15 Aug 2005 15:52:37 -0400

>>We already have examples in RFC 3720 where we report SCSI Sense data in
response to iSCSI protocol confusion.

I've always wondered about these kind of examples. Exactly what is the 
initiator supposed to do when it finds that the target has reported a 
protocol error?

Do you think the initiator will try a different method. It will probably 
resend the same PDU, close the connection, crash or do something else 
stupid. To me the target should send the reject/sense data but should then 
close the connection and let the author of the initiator code fix his bug.

Eddy

---

From: Paul Koning <[email-masked]>
Date: Mon, 15 Aug 2005 16:03:17 -0400

>>>>> "Eddy" == Eddy Quicksall <[email-masked]> writes:

 >>> We already have examples in RFC 3720 where we report SCSI Sense
 Eddy> response to iSCSI protocol confusion.

 Eddy> I've always wondered about these kind of examples. Exactly what
 Eddy> is the initiator supposed to do when it finds that the target
 Eddy> has reported a protocol error?

Right.

I can't see any sense in spending effort on complicated rules for
protocol errors.  Just nuke the session and walk away.

	 paul

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 15 Aug 2005 16:20:33 -0400

BTW, I didn't mean to duck your original issue and that is "what sense data 
should be given for particular errors". I think there are people on the 
reflector that are familiar with that issue so I will look forward to those 
responses.

Thanks,

Eddy