Bug 137555 - loopback adapter fails to send packets over 15984 bytes large
loopback adapter fails to send packets over 15984 bytes large
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-10-29 10:14 EDT by Martijn Vernooij
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:15:19 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 Martijn Vernooij 2004-10-29 10:14:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914

Description of problem:
I was having problems with Cups not sending printjobs over a certain
size. From a lot of tracing I noticed that certain packets just seemed
to disappear, with the data staying in the writeq of the sending process.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
I tested this with the 'sock' program from stevens' TCP/IP illustrated
vol 1, found at:


unpack the tarball; ./configure

cd lib
vi unp.h and remove the in_pktinfo struct (it's in the kernel headers).
cd ../sock

now open two terminals. In one, do:

strace ./sock -s -U 3457

This means: start a server, make it SO_REUSEADDR on that address/port

in the other, do:

strace ./sock -i -w 15984 -p 100 3457

Which means: send a test pattern in 15984 bytes size parts with 100 ms
in between to that server

You will see that it connects, then sends packets with some pattern in
them to the other size. Press break and both programs will end.

Start them again, but now with 15985 instead of 15984. You will see
that the packets queue up in the sending program. They never get to
the server.

Actual Results:  data stays on the sending side.

Expected Results:  data goes over the connection to the receiving side.

Additional info:

Testing by comparing the output of iptables-save -c before and after
sending shows that no packets are being blocked, only counters with
ACCEPT targets change.
Comment 1 Martijn Vernooij 2005-03-04 04:22:02 EST
Hello? Anyone home? Is this a supported version of RedHat?
Comment 2 RHEL Product and Program Management 2007-10-19 15:15:19 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.
Comment 3 Martijn Vernooij 2007-10-21 17:55:16 EDT
I'd like to note that this rediculous approach of support of a paid-for product by RedHat has (about a year 
ago) made me decide never to use, buy or recommend any product from RedHat ever again. Goodbye!

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