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
On Sat, Apr 3, 2021 at 11:21 PM Rick Macklem <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/nfsv4