NFS problem?

Don Lewis truckman at FreeBSD.org
Thu May 8 12:23:37 PDT 2003


On  8 May, Matt Douhan wrote:
> The problem is that certain-sized fragmented packets get truncated by
> the card when the card is programmed in a mode to use some new features
> that this particular Ethernet chip has available.  In the short term,
> the solution to your problem is to patch your copy of the fxp driver so
> that this chip is treated like an older model.  If you can't do that,
> then change your NFS mount options to use TCP, which will avoid the
> packet fragmentation.
> 
> 
> We already use TCP for the NFS mounts and I still see the exact same
> problems

I only saw the problem on packets that were broken into three or more
fragments, but I don't know why it couldn't happen with two fragments,
as in the case at the start of this thread, or possibly even with an
unfragmented packet in the bad range of sizes.  If you're not doing
VLANs, try pinging from client to server with packets of size
216+(N*1480):
	ping -c 216
	ping -c 1696
	ping -c 3176
	ping -c 4656

When you trigger the bug, you won't get a response, and the ip
"fragments dropped after timeout" counter in the "netstat -s" statistics
will increment, at least in the case of fragmented packets.  If you
sniff the wire with tcpdump, you'll see the "truncated-ip" message.  On
the broken machine, the tcpdump output will look normal because tcpdump
is capturing the packets before they are corrupted by the NIC.

I didn't see any problems until I hit the third size.

If you are affected by this bug, please document the hardware involved,
including the exact chip part number if possible, the pciconf -l output,
and which version of the fxp driver you are using.


More information about the freebsd-stable mailing list