Re: Nfs over tcp retries



Andy Chittenden wrote:
Here's a sequence of packets captured at the end of a NFS connection and
the start of the next for a RH Fedora Core 6 client:

# cat ~/tmp/28852a.txt
...

As you can see in packet 3, the nfs server's sent a FIN-ACK which is
acknowledged in packet 6 by the client. So by packet 8, the connection's
closed. The client attempts to reconnect to the server in packet 8 which
is refused by the server in packet 9 as the client is using the same
port number as the previous session: the server's in TIME WAIT from the
previous connection and the initial send sequence number of this new
connection is below the highest sequence number of the previous
connection. The client's attempts to reconnect continue unsuccessfully
until 2MSL is exceeded.

So, a few questions:

* why does the NFS client reuse the same source port number (894 in the
example above)?
* if the socket's being reused, why is the ISS being chosen such that
it's within the same range as the last successful connection?
* why does the ISS seem to go up by only 3 since the last attempt to
connect?

If the linux NFS client had used a different source port number or
chosen an out-of-range ISS, then its reconnection attempts would have
been successful in a more timely manner.

I suspect that the NFS client attempts to reuse the same port number
for the new connection so that it does not invalidate the duplicate
request cache on the server. NFS servers typically use the entire
IP address of the client, including the port number, when performing
the tests to check to see if the current request is the duplicate of
a previous request.

ps
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: Access Windows 2000 shares over tunnel
    ... > conclusion that this must be a transport (i.e. packet flow) problem. ... the MTU to 1500 resulting in fragments. ... I believe that if the client is on a dial-up connection, ...
    (comp.unix.bsd.freebsd.misc)
  • Nfs over tcp retries
    ... As you can see in packet 3, the nfs server's sent a FIN-ACK which is ... acknowledged in packet 6 by the client. ... previous connection and the initial send sequence number of this new ...
    (Linux-Kernel)
  • Re: TCP packets : end of thre-way handshake and start of data-transmission - how to dete
    ... Its not the client actually sending data before it should I'm concerned ... client behaves as if I did not send that packet at all (mind you, ... RFC 793 Section 3.4 (Establishing a connection) says in part: ... packet because it would be necessary to assume a window size. ...
    (comp.arch.embedded)
  • Re: Diagnose co-location networking problem
    ... to run tcpdump on my Linux client, ... I'd start by looking in clientside.dmp for failed connection ... you should see a very low packet count for the connection. ...
    (freebsd-net)
  • Re: Problems w/ Debian firewall and Windows VPN
    ... the last packet being sent is a TCP Zero Window ... > connection starts fine, but after 5-10 minutes, it disconnects. ... > client is a TCP RST, ...
    (Debian-User)