Bug 10983

Summary:	Problems in repetitive UDP and ICMP packets originating from X-Terminal
Product:	[Retired] Red Hat Linux	Reporter:	Jari Turkia <redhat-bugzilla>
Component:	kernel	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-04-26 11:39:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jari Turkia 2000-04-22 08:14:09 UTC

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 11:18:59 UTC

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 19:08:59 UTC

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 11:39:59 UTC

With the help of ARP-people (ak, alan.org.uk,
andrewm.au) the problem was finally resolved to be a problem in the
Tektronix firmware.