stuck in nfsfsync
    Aggelos Economopoulos 
    aoiko at cc.ece.ntua.gr
       
    Mon Jan 24 15:34:54 PST 2005
    
    
  
On Tuesday 25 January 2005 00:32, Matthew Dillon wrote:
[...]
>     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 ?
Just a home network:
(internet) ---- [ADSL router] ---- rl1 [OpenBSD] rl0 --- re0 [DragonFly]
>     What is the path going between these two machines?
Direct link over a crossover cable.
>     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.
That's not very easy for me to test. I could bring in a third machine when I 
have some free time (after Thursday) but I don't have a hub and I'm not sure 
they still sell them where I live. We'll see.
>     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.
That's easier. I'll put rl1 on the dragonfly box and retest (tomorrow).
Thanks,
Aggelos
    
    
More information about the Bugs
mailing list