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 http://technet.microsoft.com/en-us/library/gg983494(v=ws.10).aspx: > > 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 SUSE Labs -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to firstname.lastname@example.org. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.