But also in RFC-3720: "10.13.3. TSIH The TSIH is the target assigned session identifying handle. Its internal format and content are not defined by this protocol except for the value 0 that is reserved. With the exception of the Login Final-Response in a new session, this field should be set to the TSIH provided by the initiator in the Login Request. For a new session, the target MUST generate a non-zero TSIH and ONLY return it in the Login Final-Response (see Section 5.3 Login Phase)."
Note the last sentence. Th Solaris iScsi target is returning a TSIH in it's first login response. In this case, with the HP boot iscsi initiator, there is a second stage login packet, to which the target never responds. If the target were to respond maybe it should be giving a valid TSIH in the second (last) response. I do find RFC-3720 very difficult to understand. I think the writers of the targets & initiators get confused about what it does actually means, resulting in problems like we are experiencing in this case. I'm not sure now if it the target or the initiator that is in disagreement with the standard! Regards Nigel This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
