Date: Fri, 02 Apr 2004 16:44:02 -0800 From: Sean McNeil <sean@mcneil.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-current@freebsd.org Subject: Re: nfs server issues Message-ID: <1080953041.51638.11.camel@server.mcneil.com> In-Reply-To: <20040403000742.GD49311@dan.emsphone.com> References: <1080882894.5980.26.camel@server.mcneil.com> <20040402163353.GC6724@dan.emsphone.com> <1080940409.3711.1.camel@server.mcneil.com> <20040402215745.GB49311@dan.emsphone.com> <1080949413.49158.27.camel@server.mcneil.com> <20040403000742.GD49311@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2004-04-02 at 16:07, Dan Nelson wrote: > 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 @ 0x000000000 (DF) > > > > 13:02:57.567266 server.mcneil.com.nfs > free.mcneil.com.1360032988: reply ok 1472 readdir (frag 1645:1480@0+) > > > > 13:02:57.567268 0.0.0.1 > 0.0.10.7: (frag 1645:4@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 @ 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). Bingo! It looks like a problem with checksum offloading: ifconfig re0 -rxcsum -txcsum and now it no longer hangs. Good call! The NIC in question is: re0: <RealTek 8110S Single-chip Gigabit Ethernet> port 0xa400-0xa4ff mem 0xdf004000-0xdf0040ff irq 12 at device 11.0 on pci1 The extremely odd thing is http, ldap, samba, and many other services that go both to the box and are sent out via nat all work fine. nfs is the only protocol I've seen that has an issue. I am happy now :) Cheers, Sean
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1080953041.51638.11.camel>