Re: nfs server issues

On Fri, 2004-04-02 at 13:57, Dan Nelson wrote:
> In the last episode (Apr 02), Sean McNeil said:
> > On Fri, 2004-04-02 at 08:33, Dan Nelson wrote:
> > > "tcpdump -s0" output might help here, I think.  Do it from both
> > > machines and make sure no packets are being dropped, and then check
> > > to see what NFS request the client is trying to make that isn't
> > > getting processed.
> > 
> > OK, here is a tcpdump.  It is confusing. It looks like after the
> > first fragment is received it is looking up some bazaar IP
> > address....
> > 
> > 13:02:57.566952 free.mcneil.com.1360032988 > server.mcneil.com.nfs: 136 readdir fh 1002,54097/7890231 4096 bytes _at_ 0x000000000 (DF)
> > 13:02:57.567266 server.mcneil.com.nfs > free.mcneil.com.1360032988: reply ok 1472 readdir (frag 1645:1480_at_0+)
> > 13:02:57.567268 0.0.0.1 > 0.0.10.7: (frag 1645:4_at_1480)
> > 13:03:01.766943 arp who-has server.mcneil.com tell free.mcneil.com
> > 13:03:01.767040 arp reply server.mcneil.com is-at 0:d:61:27:4d:6b
> 
> Weird.  Is this at the server or the client?

This is a client-side dump.  Both server and client have MTU of 1500.

Server side says:

15:37:44.292564 IP free.mcneil.com.851449566 > server.mcneil.com.nfs:
136 readdir fh 1002,54097/7890231 4096 bytes _at_ 0x0
15:37:44.292705 IP server.mcneil.com.nfs > free.mcneil.com.851449566:
reply ok 1472 readdir
15:37:44.292711 IP server.mcneil.com > free.mcneil.com: udp

Is there something in a packet that tells rpc/nfs to reassemble with
something other than the source/destination info?

Sean