Re: ISCSI: CmdSN in non-leading login

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Fri, 10 May 2002, Mark S. Edwards wrote:

> There are a couple of problems here for the target.  At what point is a
> non-leading connection considered to be part of the session ?  Is it the
> moment that the login request is received with a non-zero TSIH ?  Or is it
> only when the non-leading login succeeds and it enters full feature phase ?

I think the target shouldn't let anything from a new connection influence
things until after at least the security phase has been passed. Otherwise
we have a security hole. After operational negotiation would probably be
best.

> So, should an initiator set the CmdSN in the first login request to zero
> and only synchronise with the session command stream after full feature
> phase is established ?  This is my preferred option.
>
> What happens if the initiator tries using the current session command
> sequence number is that whilst the login negotiation occurs, other
> connections within the session can be issuing new commands, so by the time
> that the login is finished the CmdSN exchanged in the initial request is
> invalid anyway.
>
> I would like to see something along the lines that for a non-leading
> connection, the CmdSN field MUST be zero and that the connection can not be
> considered part of the session until full feature phase is entered, at
> which point any commands issued on the connection are now synchronised with
> the session command sequence number as observed by all other existing
> connections on the session.

I thought login counted as a command, so it got its own command number, in
the stream of all other commands. ??

Take care,

Bill