StarWind Software

...
9/20 22:29:36.397 6c8 C[1], LIN: recvData returned 10054
9/20 22:29:36.427 6c8 C[1], LIN: *** 'recv' thread: recv failed 10058.
9/20 22:29:36.427 6cc T[1,2] CmdSn 0, ITT 0x0 - aborted.
9/20 22:29:36.427 6cc T[1,2]: state 0x3, immediate 1, ITT 0x0, CmdSn 0, TTT 0x4
9/20 22:29:36.437 6cc T[1,2]: read/write 10, read length 8, read done 0, write length 0, write done 0, DATA-IN PDUs 0
9/20 22:29:36.437 6cc T[1,2]: DataSN 0, R2TSN 0, status 0, status class 0, status detail 0, response 0, counter 0, authStage 0
9/20 22:29:36.437 6cc T[1,2]: CDB
0000 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 %...............
9/20 22:29:36.447 6cc T[1,2]: Session [1]. An aborted task completed.
9/20 22:29:36.457 6cc Tgt: : close 'iqn.yushang.com:vdisk.0001': 0 session(s) opened, 1 more allowed.

I'm testing SCSI READ_CAPACITY , but got above log . It seems no DATA-IN PDU is generated . Does the target support this SCSI command ? Thanks in advance

Hi,
from the partial log data it seems that the initiator dropped the connection before the SCSI command completion.

For debug purposes it is helpful to enable verbose logging in the StarWind service (level 2).

Yes , that's because I close the initiator . But if I didn't , I can't even get this log and target will keep no responding .
BTW , Target can respond to Nop-Out PDU.

yushang wrote:Yes , that's because I close the initiator . But if I didn't , I can't even get this log and target will keep no responding .
BTW , Target can respond to Nop-Out PDU.

Could you send me a zipped network dump file generated by Wireshark for a failed session?
The corresponding StarWind log file with LogLevel=3 is also needed.

Are there any iSCSI target working with your initiator?
If yes, please send me also a network dump from a successful session from your initiator.

Another way to go for you could be analyzing of a successful netwok dump of iSCSI session from the MS initiator to StarWind.
This could give you some ideas about the difference in requests of your initiator...

Thanks . I have found by analyzing the packet that initiator forgot to set the final bit of SCSI Read Command , that's why target didn't respond .

yushang wrote:Thanks . I have found by analyzing the packet that initiator forgot to set the final bit of SCSI Read Command , that's why target didn't respond .

Great!