I've been experiencing strange problems with nfs and ip_conntrack for a
while now,
unfortunately noone so far was able to help. The problem occurs when
ip_conntrack
is loaded on the nfs server. nfs reads hang and the clients start logging
UDP: short packet: 192.168.0.1:0 0/120 to 192.168.0.23:0
UDP: short packet: 192.168.0.1:6439 28562/120 to 192.168.0.23:60558
There are two ways to make it work: 1. remove ip_conntrack or 2. set mtu
to 1484 on
the nfs server. One suspicion was ip_conntrack breaking udp path mtu
discovery
since it seems to defragment packets with DF|MF and refragment them
(with possibly
different mtu) at POSTROUTING. This doesn't seem to be the problem, but
i noted the
nfs server sends out fragments with wrong destination mac.
This is a packet captured on 192.168.0.23:
0:e0:7d:74:ab:cc 0:e0:7d:74:ab:cd 0800 1514: 192.168.0.1 >
192.168.0.223: (frag 44777:1480@4440+) (ttl 64, len 1500, bad cksum 2294!)
This happens every 1-30 seconds. I never saw more than one misdirected
fragment per packet.
Relevent parts from neighbour table:
192.168.0.223 dev eth0 lladdr 00:e0:29:3c:c1:c9 nud reachable
192.168.0.23 dev eth0 lladdr 00:e0:7d:74:ab:cd nud reachable
On 192.168.0.223 packets for 192.168.0.23 show up. Both clients time out
during reassembly.
I placed some printks though the netfilter code and ip_output.c but
couldn't find any further
pointers. I looked for broken checksums (something seems to alter the ip
after checksumming)
in ip_finish_output2, but everything is ok there. I can't see anything
netfilter related touching packets after that.
Any help and/or pointers where to look further would be appreciated.
Regards,
Patrick
|