On Feb 20, 2008 2:30 AM, Nigel Smith <[EMAIL PROTECTED]> wrote:
> 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 agree with Nigel in his doubt in that this actually could be a target issue.
Per 3720 clause 10.13.3 as quoted above, any login response except
final must carry TSIH value provided by the initiator in its initial
login request. Therefore, in the scenario discussed the target must
return TSIH=0 in all intermediate responses until Login
Final-Response. In fact we see iscsitgt sending out non-zero TSIH in
the very first response:
Frame 8 (134 bytes on wire, 134 bytes captured)
Ethernet II, Src: HewlettP_fb:ba:92 (00:1c:c4:fb:ba:92), Dst:
00:1e:0b:e8:a4:66 (00:1e:0b:e8:a4:66)
Internet Protocol, Src: 172.20.112.39 (172.20.112.39), Dst:
172.20.112.48 (172.20.112.48)
Transmission Control Protocol, Src Port: 3260 (3260), Dst Port: 4097
(4097), Seq: 49, Ack: 200, Len: 80
[Reassembled TCP Segments (128 bytes): #6(48), #8(80)]
iSCSI (Login Response)
Opcode: Login Response (0x23)
1... .... = T: Transit to next login stage
.0.. .... = C: Text is complete
.... 00.. = CSG: Security negotiation (0x00)
.... ..01 = NSG: Operational negotiation (0x01)
VersionMax: 0x02
VersionActive: 0x00
TotalAHSLength: 0x00
DataSegmentLength: 0x0000004e
ISID: 000000000000
TSIH: 0x000c
InitiatorTaskTag: 0x00000000
StatSN: 0x00000000
ExpCmdSN: 0x00000000
MaxCmdSN: 0x00000001
Status: Success (0x0000)
Key/Value Pairs
KeyValue: TargetAlias=msa60/xen/images/scg-xen02
KeyValue: TargetPortalGroupTag=1
KeyValue: AuthMethod=None
Padding: 0000
In its next Login Request, initiator obediently provides non-zero TSIH
sent by the target, which the latter rejects and closes connection,
taking it for a new connection request for the same session
(unsupported MC/S feature).
Therefore, correct target behavior would be to respond with
initiator-supplied TSIH until final response, where (for new session)
iscsitgt must reply with TSIH it has chosen for the newly established
session.
Wrt to unsupported MC/S check in iscsi_login.c, it's worth to note
that the target does not analyze connection ID of the login request
with existing TSIH, and therefore breaks RFC3720 that requires target
to treat this as 'add new connection to existing session' request only
if CID is unknown to the target. Otherwise (per 10.12.7) "A Login
Request with a non-zero TSIH and a CID equal to that of an existing
connection implies a logout of the connection followed by a Login (see
Section 5.3.4 Connection Reinstatement)".
--
Regards,
Andrey
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
