Re: nfs udp 1000/100baseT issue

["Bret Towe" <magnade@gmail.com>]

On 3/16/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >
> >a while ago i noticed a issue when one has a nfs server that has
> >gigabit connection
> >to a network and a client that connects to that network instead via 100baseT
> >that udp connection from client to server fails the client gets a
> >server not responding
> >message when trying to access a file, interesting bit is you can get a directory
> >listing without issue
> >work around i found for this is adding proto=tcp to the client side
> >and all works
> >without error
>
> UDP has its implications, like silently dropping packets when the link
> is full, by design. Try tcpdump on both systems and compare what packets
> are sent and which do arrive. The error message is then probably because
> the client is confused of not receiving some packets.

after compairing a working and not working client i found that
packets containing offset 19240, 20720, 22200 are missing
and the 100baseT client had an extra offset of 32560
on the working client it ends at 31080

the missing ones are mostly constantly missing 22200 appears every so often
on retransmission and 23680 also disappears every so often

i hope that isnt too confusing i dont use tcpdump type stuff much
(well i did give up on tcpdump and had to use ethereal...)

> >error message i see client side are as follows:
> >nfs: server vox.net not responding, still trying
> >nfs: server vox.net not responding, still trying
> >nfs: server vox.net not responding, still trying
>
>
> Jan Engelhardt
> --
>