Red Hat Bugzilla – Bug 150611
Timeout of SYN_RECV socket does not send rst packet.
Last modified: 2007-11-30 17:07:06 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): 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?
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.
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.