On Sat, Apr 3, 2021 at 11:21 PM Rick Macklem <rmacklem@xxxxxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nfsv4
