Re: nfs server issues

In the last episode (Apr 02), Sean McNeil said:
> On Fri, 2004-04-02 at 13:57, Dan Nelson wrote:
> > In the last episode (Apr 02), Sean McNeil said:
> > > 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)
> > 
> > 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?

Neither RPC or NFS are involved with fragmentation.  That's all done at
the UDP level.  I wonder if it's a NIC problem.  Can you try a
different card (maybe even a different brand of card if possible)? 
another interesting test would be to get a hub and a 3rd machine, then
do dumps with the hub on the server's port, and then the client's port. 
If you get garbled frags in both places, I'd lean toward a NIC problem
on the server.  If your card supports checksum offloading, try
disabling it (ifconfig xx0 -rxcsum -txcsum).

-- 
	Dan Nelson
	dnelson_at_allantgroup.com