Hi All:

I have tracked down a problem I was having with open-iscsi and smartd, and I 
thought I'd see if anybody else has seen this.

In my case, there is a SLES 11 server booting using iSCSI, and the iSCSI target 
is the latest Microsoft software target (version 3.3) does not form the iSCSI 
PDU correctly when REJECTing a packet.

What seems to happen is that smartd sends down an illegal SCSI command because 
it's testing for an ATA pass-through interface.

The MS iSCSI target sees this illegal PDU and sends a REJECT. But the target 
sets the StatSN incorrectly, left-shifting the StatSN value. In my case, an 
expected StatSN value of 0xd9 was returned as 0xd9000000.

The open-iscsi initiator sees this as an error and attempts recovery via 
closing the connection then reconnecting. This recovery works but greatly slows 
down communication. This slowness can cause booting to fail. Obviously, this is 
incorrect target behavior, but it seems unlikely to change any time soon.

I found the following confirmation at 

> Reject Data-out
> RFC 3720, section 10.17.3, specifies the following:
> StatSN, ExpCmdSN and MaxCmdSN: These fields carry their usual values and
> are not related to the rejected command. StatSN is advanced after a Reject.
> The behavior implemented by the Microsoft iSCSI Software Target 3.3:
> The iSCSI Software Target was observed to send the value in host native
> byte order for StatSN for the Reject PDU.

So I wondered:

1. Has anybody else seen this?, and

2. Is there any interest in putting in a work around for such behavior, since 
the MS target is quite common?
Lee Duncan

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to