Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 150611

Summary: Timeout of SYN_RECV socket does not send rst packet.
Product: Red Hat Enterprise Linux 3 Reporter: Jason Smith <smithj4>
Component: kernelAssignee: David Miller <davem>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: petrides, riel
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: 2005-03-09 00:24:12 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 Jason Smith 2005-03-08 21:52:23 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20050104 Red Hat/1.4.3-3.0.7

Description of problem:
While investigating what appears to be a problem with our firewall, I discovered that the kernel does not sent a tcp reset packet after it times out waiting for the final ack while in the SYN_RECV state.  The probably well known TCP state transition diagram from Wright & Stevens' book "TCP/IP Illustrated" shows that if a socket times out in the SYN_RECV state and goes back to being CLOSED, it should send a reset to the remote end.

Version-Release number of selected component (if applicable):
kernel-2.4.21-27.0.2.EL

How reproducible:
Always

Steps to Reproduce:
1. Start a server listening with netcat:  nc -l -p 1234
2. Block the client's reply ack with iptables:
  iptables -t filter -A OUTPUT -p tcp -m tcp --dport 1234 --tcp-flags ALL ACK -j DROP
3. Watch the packet exchange as root:  tcpdump -i lo port 1234
4. Start a client with netcat:  nc localhost 1234
5. Watch the sockets with:  netstat -tp | grep 1234

Actual Results:  tcpdump shows the server repeatedly sending the syn-ack connection reply while netstat shows the server's socket waiting in the SYN_RECV state while the client believes that it has an established connection.  After a few minutes the server times out and returns to the LISTEN state and never sends a reset.  The client will indefinitely think it has an established connection and could be hung trying to read from its half-open socket.

Expected Results:  When the socket times out it should send a reset to the client which thinks it has an established connection, to notify it that it has closed the socket.


Additional info:

Obviously the problem is rare and would only happen with a broken network and/or firewall, but shouldn't a reset be sent when timing out on a socket in the SYN_RECV state?
Comment 1 Jason Smith 2005-03-08 22:07:47 UTC 
Sorry, I didn't notice that I got sent to the "beta" page where I
submitted this bug report and the form text entry areas did not get
newlines added in like normal.  I also didn't get the
review/confirmation page before the final commit either.
Comment 2 David Miller 2005-03-09 00:24:12 UTC 
This is not a bug, there is no standard that specifies that we should
elicit a reset when we've only seen a SYN from the other end.

It's quite clear why too, because if the host won't respond to our
SYN+ACK response packets, there is no reason to belive it will receive
and process correctly any RST frame we send out as well.

If your firewall is relying on such behavior, it really is the problem
not the Linux TCP stack.