Re: stuck in nfsfsync

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Done. See the attached tarball.

    (800K tarball downloaded and analysied)

:Notes:
:
:...
:>     Right now my best guess is that it is an MTU issue or a
:>     maximum-packet-size issue on one of the machines or that your network
:>     interface simply can't handle a whole lot of IP fragments coming in at
:>     once.  The tcpdump should make things clearer.
:
:I hope so. Feel free to ask for more info.
:
:Aggelos

    Well, it looks like the last fragment the client sends is getting
    garbled somewhere.  The tcpdump on the client seems to believe that
    the packet is valid.... the last fragment looks just fine.  But the
    tcpdump on the server appears to see a corrupted packet or packet
    header.  It understands the fragment id, size, and offset, but it
    is totally confused about the IP address.

    The question is, where is the packet getting garbled?  The client
    thinks it sent out a valid packet and the server thinks it received
    a garbled one.

    How is your network setup ?  What is the path going between these two
    machines ?  The first thing I would do is connect the client's ethernet
    through a HUB and monitor the packket traffic with another machine
    connected to the same HUB, so we can be sure that the client is actually
    sending out a valid packet fragment.  If it is, then move the HUB to
    the server and look at the packets going into the server.  If they
    look good, then it is the server itself that is garbling the packet.

    It is also quite possible that the fault is the client.  A 4-byte UDP
    packet comes in under the 64 byte ethernet frame minimum, it could be
    a bug in the RE driver when dealing with tiny packets.  Further tests
    are needed.

						-Matt

[ EXTRACTION from Aggelos's packet dumps ]

CLIENT:  (RE0)

11:43:27.261710 192.168.2.2.183764104 > 192.168.2.4.nfs: 1472 write [|nfs] (frag 8031:1480@0+)
11:43:27.261718 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@1480+)
11:43:27.261729 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@2960+)
11:43:27.261743 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@4440+)
11:43:27.261756 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@5920+)
11:43:27.261767 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@7400+)
11:43:27.261781 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@8880+)
11:43:27.261793 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@10360+)
11:43:27.261807 192.168.2.2 > 192.168.2.4: udp (frag 8031:4@11840)

SERVER:  (RL0)

13:56:59.783671 192.168.2.2.183764104 > 192.168.2.4.nfs: 1472 write [|nfs] (frag 8031:1480@0+)
13:56:59.783785 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@1480+)
13:56:59.783915 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@2960+)
13:56:59.784037 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@4440+)
13:56:59.784159 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@5920+)
13:56:59.784283 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@7400+)
13:56:59.784407 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@8880+)
13:56:59.784527 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480@10360+)
13:56:59.784532 0.0.0.0 > 0.0.2.4: udp (frag 8031:4@11840)