2.4.20+bridge-nf-0.0.7-against-2.4.19.diff seems to generate broken UDP packets when kernel NFS client code does a 'largish' (a few kb) write to NFS server:
tcpdump -vvvv -n -i eth1 "udp src port 800": 13:13:36.254256 81.17.195.84.800 > 81.17.195.82.902: udp 4220 (frag 27435:1480@0+) (ttl 64, len 1500) 13:13:36.484702 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) 13:13:36.486151 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) 13:13:36.487640 81.17.195.84.800 > 81.17.195.82.902: udp 116 (DF) (ttl 64, id 0, len 144) 13:13:36.488805 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) 13:13:36.490250 81.17.195.84.800 > 81.17.195.82.902: udp 140 (DF) (ttl 64, id 0, len 168) 13:13:36.491998 81.17.195.84 > 81.17.195.82: truncated-udplength 2 (frag 27436:1480@0+) (ttl 64, len 1500) 13:13:36.492839 81.17.195.84.800 > 81.17.195.82.902: udp 8316 (frag 27437:1480@0+) (ttl 64, len 1500) 13:13:36.524286 81.17.195.84.800 > 81.17.195.82.902: udp 8316 (frag 27438:1480@0+) (ttl 64, len 1500) 13:13:36.526700 81.17.195.84.800 > 81.17.195.82.902: udp 204 (DF) (ttl 64, id 0, len 232) 13:13:36.528226 81.17.195.84.800 > 81.17.195.82.902: udp 116 (DF) (ttl 64, id 0, len 144) 13:13:36.529714 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) 13:13:36.530748 81.17.195.84.800 > 81.17.195.82.902: udp 136 (DF) (ttl 64, id 0, len 164) 13:13:36.532459 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) tcpdump -vvvv -n -i br0 "udp src port 800": 13:13:36.254216 81.17.195.84.800 > 81.17.195.82.902: udp 4220 (ttl 64, id 27435, len 4248) 13:13:36.484678 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) 13:13:36.486129 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) 13:13:36.487619 81.17.195.84.800 > 81.17.195.82.902: udp 116 (DF) (ttl 64, id 0, len 144) 13:13:36.488783 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) 13:13:36.490229 81.17.195.84.800 > 81.17.195.82.902: udp 140 (DF) (ttl 64, id 0, len 168) 13:13:36.491959 81.17.195.84.800 > 81.17.195.82.902: udp 8316 (ttl 64, id 27436, len 8344) 13:13:36.492803 81.17.195.84.800 > 81.17.195.82.902: udp 8316 (ttl 64, id 27437, len 8344) 13:13:36.524247 81.17.195.84.800 > 81.17.195.82.902: udp 8316 (ttl 64, id 27438, len 8344) 13:13:36.526678 81.17.195.84.800 > 81.17.195.82.902: udp 204 (DF) (ttl 64, id 0, len 232) 13:13:36.528204 81.17.195.84.800 > 81.17.195.82.902: udp 116 (DF) (ttl 64, id 0, len 144) 13:13:36.529693 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) 13:13:36.530728 81.17.195.84.800 > 81.17.195.82.902: udp 136 (DF) (ttl 64, id 0, len 164) 13:13:36.532436 81.17.195.84.800 > 81.17.195.82.902: udp 104 (DF) (ttl 64, id 0, len 132) I can produce this way too reliably, even saving a small text file from editor over the NFS mount is quite unreliable and hangs for a few minutes most of the time. Also it isn't completely deterministic, the same operation can first work a few times before failing. (My hunch would be that the packet is freed before it is actually sent out and sometimes the memory gets reallocated before the packet is sent.) I _think_ this might be happening with other than NFS packets also since I have seen TCP checksum failures around also, but I have no proof of that (TCP retransmits are quite a bit more efficient than NFS-over-UDP retransmits so it's kinda harder to notice). There's a lot of 'short UDP packet' and 'UDP checksum failure' messages on the NFS server log. -- Ilpo Ruotsalainen - <[EMAIL PROTECTED]> - http://www.iki.fi/lonewolf/ _______________________________________________ Bridge mailing list [EMAIL PROTECTED] http://www.math.leidenuniv.nl/mailman/listinfo/bridge
