Bug 243315 - xinetd connection failures at high rates across firewalls
Summary: xinetd connection failures at high rates across firewalls
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: xinetd
Version: 3.8
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
Assignee: Jan Safranek
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-08 15:10 UTC by Need Real Name
Modified: 2007-11-17 01:14 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-19 18:36:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2007-06-08 15:10:48 UTC
Description of problem:

The xinetd for RHEL 3 and RHEL 4 has a bug that causes some connections across
firewalls to be broken.  Two conditions seem to be required for this bug to
actually be noticed:

1.  Opening ~10 or more connections very quickly from a single client to a
single service behind xinetd.  (A delay of ~0.2 seconds between connections
seems to be enough to avoid the problem.)
2.  The client system and xinetd system are separated by (in our case) Cisco
Firewall Service Modules.

We believe this is a xinetd bug primarily because we built xinetd 2.3.14 from
source (with loadavg and libwrap) keeping everything else constant, and our
connection failures stopped.  This "fix" was successful on two servers that
we've upgraded in this way.


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

xinetd-2.3.12-6.3E.2 (on RHEL 3)  (we also saw the problem in xinetd-2.3.12-6.3E
on one node before upgrading to E.2)
xinetd-2.3.13-4.4E.1 (on RHEL 4)


How reproducible:

Very reproducible, but with variable failure rates.

Steps to Reproduce:
1.  Put a Cisco firewall between a client host and a server with a service such
as telnet behind xinetd.  Unfortunately, I don't enough about Cisco firewall
configurations to know if there are specific configurations that are necessary
to observe this problem.
2.  Script a series of ~20 connections from the client to the server to occur as
rapidly as possible within the script.
3.  Watch as a handful of those connections fail (though sometimes they will all
succeed).
4.  The broken connections are especially easy to note in tcpdumps on the
server, in which there will be an exchange of TCP retransmissions and duplicate
ACKs.  The first sign of trouble is a when the server sends a second SYN,ACK
packet.  At this point the connection is for all intents and purposes broken.
   
Actual results:

100% successful connections

Expected results:

Several failed connections (variable between ~50% and 100% successful connections.)

Additional info: 

a question:  is there any reason for Redhat not to build an updated xinetd
package from version 2.3.14?

Comment 1 RHEL Program Management 2007-10-19 18:36:27 UTC
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:
http://www.redhat.com/security/updates/errata/
 
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.


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