what defines a TCP connection as new, requiring BindConnectionToSession?

what defines a TCP connection as new, requiring BindConnectionToSession?

[Rick Macklem]

Hi,

I have been doing testing of network partitioning between a
Linux client (5.2.10) and a FreeBSD server and have observed
the following:
- If I unplug a net cable for a few minutes and the plug it
   back in, the Linux client does a TCP "SYN", expects "SYN, ACK"
   and then continues on, using the same port# as before the
   network partitioning.
--> I had assumed the above created a "new connection" that
       will only be bound to the backchannel if a
       BindConnectionToSession is done on it.
Now I am not sure if this is considered a "new connection" or
the same connection (same port#) still bound to the back channel?

I am also wondering about this para. in RFC5661 pg. 493:
   Invoking BIND_CONN_TO_SESSION on a connection already associated with
   the specified session has no effect, and the server MUST respond with
   NFS4_OK, unless the client is demanding changes to the set of
   channels the connection is associated with.  If so, the server MUST
   return NFS4ERR_INVAL.
Since a "new connection" is bound to a session's fore channel by
sending an RPC with Sequence in it, does this imply that a
BindConnectionToSession done on a connection to bind a back channel
after an RPC with Sequence in it has been done on the connection,
must fail with NFS4ERR_INVAL?

As you can see, knowing what constitutes a new TCP connection matters.

Thanks in advance for any help with this, rick

Re: [nfsv4] what defines a TCP connection as new, requiring BindConnectionToSession?

[Olga Kornievskaia]

On Sat, Apr 3, 2021 at 11:21 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:
>
> Hi,
>
> I have been doing testing of network partitioning between a
> Linux client (5.2.10) and a FreeBSD server and have observed
> the following:
> - If I unplug a net cable for a few minutes and the plug it
>    back in, the Linux client does a TCP "SYN", expects "SYN, ACK"
>    and then continues on, using the same port# as before the
>    network partitioning.
> --> I had assumed the above created a "new connection" that
>        will only be bound to the backchannel if a
>        BindConnectionToSession is done on it.
> Now I am not sure if this is considered a "new connection" or
> the same connection (same port#) still bound to the back channel?

My understanding is that the client has created a new connection
regardless if it reused the source port. At this point this connection
is not bound to anything until either the client sends something with
a SEQUENCE in it which will make it bound to the forechannel or the
client must send as the first operation BIND_CONN_TO_SESSION asking
for both and/or backchannel binding if the client wants to have this
connection bound to the callback channel.

> I am also wondering about this para. in RFC5661 pg. 493:
>    Invoking BIND_CONN_TO_SESSION on a connection already associated with
>    the specified session has no effect, and the server MUST respond with
>    NFS4_OK, unless the client is demanding changes to the set of
>    channels the connection is associated with.  If so, the server MUST
>    return NFS4ERR_INVAL.
> Since a "new connection" is bound to a session's fore channel by
> sending an RPC with Sequence in it, does this imply that a
> BindConnectionToSession done on a connection to bind a back channel
> after an RPC with Sequence in it has been done on the connection,
> must fail with NFS4ERR_INVAL?

That's correct as per my understanding. If a client established a
connection, then say it sent something already with a SEQUENCE and
then tried to send BIND_CONN_TO_SESSION asking for the backchannel to
be bound to this existingconnection, the server must error with
ERR_INVAL. I had to fix the linux client for this as the client was
trying to change the backchannel binding after the channel was already
bound to just the forechannel.

> As you can see, knowing what constitutes a new TCP connection matters.
>
> Thanks in advance for any help with this, rick
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4