I got some feedback on this from Rick McNeal (Original author of the Solaris iscsi target).
Rick said: "I haven't seen the trace. Can you look to see if the initiator is requesting full feature mode as the next stage? If not, then target shouldn't be generating the tsih value. At least that's how I would interpret the paragraph you posted." Rick, thanks for your insight. If you look at the trace, the first login packet is NOT requesting transition to "Full-feature phase", In the first login (packet #4) the NSG field is "01" asking for next phase of "Operational Negotiation". Only in the seconds login (packet #10), is the NSG field "11" asking for full-feature. So it looks like the first target response (packet #6), where it is returning a non-zero TSIH, is in violation of RFC-3720. Having said this, AFAIK no other iscsi initiator has exposed this issue. Most initiators seem to have a policy of using TSIH of zero in any login packet, and only use a TSIH value from the final login response, and ignore that fact that a non-zero TSIH has been supplied at an earlier stage. So one of the questions now is, what changes are required to the Solaris iscsi target code, to give RFC-3720 compliant TSIH during login response packets? (I'm out of time again for tonight...) Best Regards Nigel Smith This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
