Red Hat Bugzilla – Bug 10983
Problems in repetitive UDP and ICMP packets originating from X-Terminal
Last modified: 2008-05-01 11:37:55 EDT
Kernel version: 2.2.14-6.1 Bug found with: ping & TFTP First off, this bug is not reproducible from NT or Linux boxes. Tried that many times. The problem was first encountered with my Tektronix XP337 X-Terminal. It contains enough capability on ROM that it can do pings and load its operating system via TFTP. This worked fine with 2.0.x series kernels. It worked fine with RedHat 6.0 (kernel 2.2.5). But now on latest kernel ping stops after <100 packets and starts to do no response. Similar effect can be detected while loading the operating system. This great number of UDP packets going in and out seem to have similar effect. Also I measured the packet traffic to halt after 5 seconds (wristwatch, not accurate). This is the case in ping and TFTP. So I can ping as much as I want under 5 seconds. Unfortunately the X-Terminal operating system takes 10+ seconds to load. Since this almost looks like a feature, I disabled SYN cookie from kernel but it did not help.
Using sniffer tools the exact nature of the problem has been discovered. The network interface card used in this environment is 3Com 509. The X-Terminal has built in Tektronix ethernet circuitry. In my sample run 77 IMCP echo (ping) packets were correctly received and echoed back (IPchains packet logging confirms this). After 78th packet ICMP echo fails continuously. The reason for failing according to captured ethernet packet is that the source and destination stations ARE EXACTLY THE SAME! In plain words, the packet is destined to the same station that sent it. 77 times the ethernet header is correctly (MAC) addressed from originating station to receiving one, but after that one the destination ethernet header at the Linux end is seriously conflicting the IP header in the very same packet (which btw. is correctly set). To my understanding this flaw on the ethernet level is also the reason for failing UDP packets.
As instructed by Mr. Donald Becker I also checked out for any ARP-traffic on the LAN when things start going wrong and found that none was present. This strongly indicates a bug somewhere in the TCP/IP code.
With the help of ARP-people (ak@suse.de, alan@lxorguk.ukuu.org.uk, andrewm@uow.edu.au) the problem was finally resolved to be a problem in the Tektronix firmware.