Jump to content
SNS Users' Forums
  • Announcements

    • Eric Newbauer

      Forum closed   06/30/2018

      PLEASE NOTE: This forum is closed and no longer moderated. Please visit https://www.studionetworksolutions.com/support/ for assistance with your SNS products. Follow Studio Network Solutions on Twitter. Thank you!


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About zmark

  • Rank
  1. After a while of being on the back burner, I resolved the compatibilty issues. Turns out it was a bug in our target that doesn't properly set the TSIH on the last login response of the login phase (the issue was discovered when testing with a hardware HBA card). It exposed a bug in the GlobalSAN initiator as well as our development target. It explains why setting the T bit on the last login response to 0 allowed the login to continue: 1) Our target was using a hardcoded TSIH of 0 which was correct given that it was the leading login request for a session. 2) The GlobalSAN protocol validator module looked at the login response PDU, saw the 0 TSIH (which matches what it used to login) and a T bit of 0 and processed the PDU as valid. The GlobalSAN initiator did not do a higher-level validation of the PDU because the login proceeded. As far as I can tell, RFC3720 indicates that the negotiation should continue given that protocol sequence. I'm surprised that the Solaris PDU validators didn't catch this given their general pedanticism about protocol. But RFC3720 is so poorly written that issues like this can easily slip through the cracks.
  2. Seeing that the same problem occurs with the Solaris target I'm fairly confident that the globalSAN initiator is protocol-incorrect. The Solaris iSCSI platform seems (to me) to be built on pedantic levels of protocol compliance and it's precisely why I enjoy testing with their initiator, because it brings out the compliance bugs that I never would have caught otherwise. Granted their target may have been developed by a different team, but the general Sun philosophy comes into play here and I'm far more confident that Sun's implementation is correct than that of SNS.
  3. Any update on this from SNS (or any other protocol experts for that matter)? I have packet captures ready to send.
  4. Hello, I am currently developing an open-source iSCSI/SCSI target implementation and I am having some difficulty getting the globalSAN initiator to play well with our target, which was written in-house. Currently, our target is compatible with Microsoft Software iSCSI Initiator, as well as OpeniSCSI on Linux. We are attempting to round out our offering by making our software compatible with the GlobalSAN initiator. To be more specific about my troubles, I attempted to perform two operations with the GlobalSAN initiator to our target: 1) Target discovery via SendTargets 2) Manual login to the target via pre-defined IQN. No security was enabled in either case. Header and data digests were disabled. Both cases produce the same symptoms. I have packet captures taken with Wireshark that show the following behavior: 1) The initiator sends a login PDU to our target, as expected. The T bit is set to 1, indicating that the initiator would like to enter the full feature phase after this PDU. 2) Our target responds with code SUCCESS with some operational parameters as well, and leaves the T bit (indicating the desire to transition to the full feature phase) to 1. 3) The initiator sends a TCP RST (connection reset) which our target acknowledges, and the connection is reset. A log message appears in syslog ("invalid login response") and a dialog box appears with the message "Could not login to target <iqn> globalSAN error code 120D." I take it that error code 120D is the code for an invalid login response (I was unable to find any documentation of the error codes). The reason I focus so much on the T bit is that by adjusting our implementation to set the T bit to 0 on the login response, the initiator begins sending SCSI commands (as if the login were successful). Is our target implementation incorrect in setting the T bit to 1 in the case of this login response? I've looked through RFC3720 extensively on this matter, and I haven't found any specific verbiage. The Microsoft, OpeniSCSI, and Solaris initiators do not exhibit this behavior. I can send along the packet captures if requested. Thank you, Zachary Mark Software Engineer Cleversafe, Inc. http://www.cleversafe.org