Bug 10983 - Problems in repetitive UDP and ICMP packets originating from X-Terminal
Problems in repetitive UDP and ICMP packets originating from X-Terminal
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
Depends On:
  Show dependency treegraph
Reported: 2000-04-22 04:14 EDT by Jari Turkia
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-04-26 07:39:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jari Turkia 2000-04-22 04:14:09 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.
Comment 1 Jari Turkia 2000-04-23 07:18:59 EDT
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.
Comment 2 Jari Turkia 2000-04-25 15:08:59 EDT
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.
Comment 3 Jari Turkia 2000-04-26 07:39:59 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.