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
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 (firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org) the problem was finally resolved to be a problem in the