3

I have a Windows 2008 server and an application that connects over Internet to it. From time to time I see that I receive a TCP [RST, ACK] that is ignored by my application. Using TCPViewer I still can see that connection is still up. I did different Wireshark captures and I can see that in case of the RST ignore, another packet is send back, and the connection is never dropped.

269037  72.5.42.235 172.16.1.138    TCP 60  9003?54020 [RST, ACK] Seq=2655287284 Ack=371936778 Win=0 Len=0
269038  172.16.1.138    72.5.42.235 TCP 66  [TCP Dup ACK 268965#33] 54020?9003 [ACK] Seq=371936778 Ack=2655238984 Win=2097120 Len=0 SLE=2655243124 SRE=2655287284

This usually happens when the connection is bad and I get a lot of latency, delayed packets and retransmissions. Can somebody explain the situation when a [RST, ACK] may be ignored by an application or operating system?

0
2

A TCP connection is normally terminating using a special procedure where each side independently closes its end of the link. Connections are only a pair of two-way handshakes, not the normal 3-way handshake some people expect. Normal connection shutdown states are different at each end. It normally begins with one of the application processes signaling to its TCP layer that the session is no longer needed. That device sends a FIN message to tell the other device that it wants to end the connection, which is acknowledged. When the responding device is ready, it too sends a FIN that is acknowledged; after waiting a period of time for the ACK to be received, I believe its 4 mins, the session is closed.

The TCP protocol detects and responds to various problems that can occur during an established connection. One of the most common is the half-open connection. This occurs when one device closes the connection without the other one knowing about it, due to some problem with the connection, such as a bad network connection continuously flapping, which sounds like what you're experiencing. This means one device is in the ESTABLISHED state while the other may be in the CLOSED state, or some other transient state. This can cause states of the two devices to become unsynchronized.

TCP handles these half-open connections with the RST reset function, which is is generated whenever something happens that is “unexpected” by the TCP software.

Your client issued the RST, your http server ACK'd the RST, which should have closed the connection. However, because of the network flapping and the connection being half-open and unsynchronized, this caused some packet-loss or received out of order. This is why you also see the DUP ACK in your post.

2

To close a whole TCP connection you need to close it on both sides. If one side closes the connection from its side, another side can have that connection opened as long as it wants.

You can check here how it works http://en.wikipedia.org/wiki/Transmission_Control_Protocol

3
  • I understand that a connection needs to be closed on both sides, and I see the RST, ACK from the server on my client, but for some reason the client just ignores that RST packet and keeps the connection open. – Adrian R Oct 2 '14 at 21:52
  • 2
    Many windows apps are notorious for using RST to terminate a connection as it "saves" a few packets here and there from being transmitted. – Remi Letourneau Oct 3 '14 at 15:09
  • @RemiLetourneau I thought it was just laziness? Closing a socket sends RST. "Graceful close" is more complicated and who wants to bother learning that when you can just close the socket? – user253751 Apr 1 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.