Anyone here familiar with iSCSI protocol? I have been sniffing around at some iSCSI traffic and have been working on making a compliant iSCSI server app. Things have been going relatively smoothly until recently. There's a LOT of setup required before you can even get to doing your first Read and Write commands. I got through a whole bunch of it, comparing the results of my server against a known SAN device. My problem, however, which I do not necessarily blame on the client, is that the first Write(10) command that comes to my server appears to request that I write 1 Logical Block to the disk, however, the payload for the packet is not existent and the "DataSegmentLength" field is 0. I expected, with 1 logical block being written, that the DataSegmentLength field would be 0x00000200 (512 bytes). I've attached a capture if anyone is so motivated to look at it.... it isn't very long. Download the Capture of MS iSCSI initiator making bad requests to my iSCSI Development Server It should also be noted that if I accept this Write(10) request and handle it as defined in the spec, it will continue Sending me 0 length Write requests until the the Initiator reports "Device I/O Error". My server generates no errors. Thanks in advance for your time, Jason Update: I noticed that ExpCmdSN was looking a little higher than would be expected. I corrected the handling of it. It made no difference in the final outcome however. The attached link reflects the capture BEFORE I made that change. asked 19 Jun '13, 08:23  evilrobot edited 19 Jun '13, 12:00 |
One Answer:
At least in the packet capture you uploaded the total packet length displaying is 102 bytes (from initiator for the data write case) which means 14bytes eth header + 20 bytes IP header + 20 bytes TCP Header + 48 bytes ISCSI header. So no data is exactly written to the target and no error responses were seen.Let me know if i am missing anything here... If you look at the Login command header(packet.no 23) from initiator the ImmediateData=Yes and InitialR2T=no and if you look at the Login response(packet.no 24)header the Immediatedata=NO and InitialR2T=yes. Quoting RFC If ImmediateData is set to Yes and InitialR2T is set to No, then the initiator MAY send unsolicited immediate data and/or one unsolicited burst of Data-Out PDUs. Which is your case1(Login request) If ImmediateData is set to No and InitialR2T is set to Yes, then the initiator MUST NOT send unsolicited data and the target MUST reject unsolicited data with the corresponding response code. Which is your case2(Login response) Is this clue makes sense? Let me know. answered 19 Jun '13, 12:35  krishnayeddula edited 19 Jun '13, 12:36 |
Thanks for the reply. I am fairly new to this protocol, so you're probably more on top of the rules and specs than I am and I'll look into your suggestion and report back.
My login negotiation code is still somewhat of a stub but unless I missed something, it matches the replies of the model I sniffed and therefore the initiation gets exactly what it is accustomed to getting, but it only makes sense to me that the Initiator would send me a 0-byte write request if something in the setup is broken.
Thanks again.
Yes, it appears that the Yes/No values for ImmediateData and InitialR2T were reversed and changing that fixed the Write commands sent from the initiator. I'm still getting I/O errors, but the most obvious problem with the writes appears to be fixed, thankyou!