stuck in nfsfsync
Matthew Dillon
dillon at apollo.backplane.com
Mon Jan 24 14:32:50 PST 2005
: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 at 0+)
11:43:27.261718 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 1480+)
11:43:27.261729 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 2960+)
11:43:27.261743 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 4440+)
11:43:27.261756 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 5920+)
11:43:27.261767 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 7400+)
11:43:27.261781 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 8880+)
11:43:27.261793 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 10360+)
11:43:27.261807 192.168.2.2 > 192.168.2.4: udp (frag 8031:4 at 11840)
SERVER: (RL0)
13:56:59.783671 192.168.2.2.183764104 > 192.168.2.4.nfs: 1472 write [|nfs] (frag 8031:1480 at 0+)
13:56:59.783785 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 1480+)
13:56:59.783915 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 2960+)
13:56:59.784037 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 4440+)
13:56:59.784159 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 5920+)
13:56:59.784283 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 7400+)
13:56:59.784407 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 8880+)
13:56:59.784527 192.168.2.2 > 192.168.2.4: udp (frag 8031:1480 at 10360+)
13:56:59.784532 0.0.0.0 > 0.0.2.4: udp (frag 8031:4 at 11840)
More information about the Bugs
mailing list