Bug 150611 - Timeout of SYN_RECV socket does not send rst packet.
Timeout of SYN_RECV socket does not send rst packet.
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-03-08 16:52 EST by Jason Smith
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: 2005-03-08 19:24:12 EST
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 Jason Smith 2005-03-08 16:52:23 EST
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):

How reproducible:

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 17:07:47 EST
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-08 19:24:12 EST
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.

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