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

From: [email-masked]
Date: Fri, 12 Aug 2005 09:41:45 -0400

Bill,

>> if it examined TTT before ITT, then the Data-Out PDU wouldn't match a 
task 
>> and no task would be impacted.

I agree.  The target should probably send a reject PDU.

>> Would Sense Key Aborted Command (0x0b), ASC/Q 0x4b/0x00 Data Phase 
Error be appropriate? 

That makes sense to me.  I've seen targets return 4b 00 in the case of a 
data direction error and data size mismatches on FC and parallel SCSI. (By 
the way - anyone know what 4b 01 Invalid Transfer Port Target Tag is for?)

BUT . . . Since this is may be a recoverable transport error, not a SCSI 
error, why abort the SCSI task at the target?  Seems to me that the target 
should send a reject PDU and wait for the initiator to try to fix the 
problem.  The target doesn't know if this error is recoverable or not, and 
the initiator can always use task manglement to abort the command itself.

regards,

david

David J Cuddihy, Principal Engineer 
ATTO Technology, Inc. 
http://www.attotech.com/bridge.html 

William Studenmund <[email-masked]> 
Sent by: [email-masked]
08/11/2005 10:11 PM

To
ISCSI <[email-masked]>
cc

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

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

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

---

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

On Aug 12, 2005, at 6:41 AM, [email-masked] wrote:

> Bill,
>
> >> if it examined TTT before ITT, then the Data-Out PDU wouldn't match 
> a task
> That makes sense to me.  I've seen targets return 4b 00 in the case of 
> a data direction error and data size mismatches on FC and parallel 
> SCSI.  (By the way - anyone know what 4b 01 Invalid Transfer Port 
> Target Tag is for?)

Google says it's a SAS thing.

> BUT . . . Since this is may be a recoverable transport error, not a 
> SCSI error, why abort the SCSI task at the target?  Seems to me that 
> the target should send a reject PDU and wait for the initiator to try 
> to fix the problem.  The target doesn't know if this error is 
> recoverable or not, and the initiator can always use task manglement 
> to abort the command itself.

I actually talked about a few error cases in the original message. Some 
of them may be recoverable, while others may not. I'm now tempted 
(after this and Paul's note) to just handle ITT/TTT mismatch as a 
reject and leave the task alone. But I think we should kill the task if 
something like Buffer Offset is wrong. Among other things, I don't want 
to try and place the data in that case. Something's wrong, so let's 
stop and try again.

Take care,

Bill

---

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

>> SCSI error, why abort the SCSI task at the target?

On TCP/IP, how can there be a recoverable transport error? For example, if 
an error is going to occur and it happens to be on the DataSegmentLength, 
then you will not be able to receive anymore PDU's (without markers and 
digests).

If the connection is such that the IP CRC is not reliable then iSCSI digests 
are in order. If you aren't using digests and you are saying you want to 
cover the cases where an error can slip by the IP CRC, the chance of an 
error hitting the ITT/TTT (or some other detectable PDU field) but nothing 
else (like undetectable PDU fields or data) is extremely small.

What I'm trying to say here is that catching a protocol error may be useful 
but catching a transport error is fruitless. This is not to say that you 
don't have a good point as to exactly what sense data to use given the 
various situations.

Eddy

---

From: Julian Satran <[email-masked]>
Date: Tue, 16 Aug 2005 10:23:47 +0300

According to SPC you could chose response code 70h (immediate) and a sense 
key of 5h illegal request - provided (as it was said already) that you can 
recognize the ITT. If you can't and you are a target then either you or 
the initiator are brain dead and you may start by closing 
connection/session etc. 

Julo

12-08-05 19:49

To
[email-masked]
cc
[email-masked]
Subject
Re: [Ips] Question about invalid PDUs and SCSI sense data

Take care,

Bill