Where do resets come from?

In Networking Support we often get calls from customers, as well as other groups within Technical Support, where someone has seen a TCP Reset frame in a network capture and they want to know "what’s wrong with the network?". Well, there isn’t necessarily anything "wrong" just because we see a TCP reset. A TCP Reset frame can be sent for various reasons, not all of which indicate a problem. Actually resets are a good thing. They allow for connections that may otherwise have been unnecessarily left open, to be closed. One example would be when an application makes lots of short-lived TCP connections and we don’t want to leave the connection on the server in a Time Wait state, so the application resets the connection, but I am getting ahead of myself.

The Three Way Handshake

First let’s talk a little about what a TCP connection is. When a node on the network wants to talk to another node on the network, using TCP, they may establish a TCP connection. To do this, the node acting as the client will send what is known as a Synchronization, or Syn frame, to the node acting as the server. This packet will contain a lot of information needed to establish the connection and transfer data. But, what we are most interested in here is the port information. The connection will actually take place between a source port on the client and a destination port on the server. The Syn frame will contain the Source Port from the sender and the Destination Port that the node wants to establish the connection to on the destination.

Side note: What’s a port, and no it’s not a place to park your boat, at least not in this case. A port is a software construct that serves as an endpoint. Think of it as a block of resources.

The following frame is an example of a Syn packet. You will notice the TCP:Flags= …….S. This indicates that this is a Syn frame. SrcPort, is Source Port, this is the port on the client that the client is using to establish the connection. DstPort, stands for destination port, which in this case is 445, the port for Direct SMB. The server will need to be listening on this port in order to accept the Syn and continue.

The connection establishment is completed in the next two frames. The second frame is an Ack, Syn frame. The server is Acknowledging the receipt of the first Syn frame and sending its own Syn frame. Both of these functions happen in the same frame. Notice the Source and Destination ports have been switched to correctly reflect the server as the source and client as the destination. The final Ack is the client Acknowledging receipt of the server’s Syn frame and completion of the connection establishment.

This connection establishment process is commonly referred to as the Three Way Handshake. We now have a connection between the two nodes on this set of ports.

Time Wait state

Earlier I mentioned the Time Wait state, so what does this mean and why is it important? When a TCP connection closes gracefully one side will send a Fin frame. This indicates that the node that sent it has nothing more to send. The second node will Ack this frame and when the second node has nothing more to send it will send its own Fin which the first node will Ack. When the Fin frames have been sent from both sides and both sides have received the Ack frame for the Fin, then the TCP connection goes into the Time Wait state. The connection will stay in time wait for a default of 4 minutes. This allows for any stray packets that might still be on the network for this connection to be passed through and allows for everything to be gracefully torn down on the two nodes.

Now that we know how to establish and "gracefully" close a TCP connection let’s talk about how and why we would want to reset a TCP connection.

Resets

So what is a reset? A TCP reset is an immediate close of a TCP connection. This allows for the resources that were allocated for the previous connection to be released and made available to the system.

SMB Reset

This brings us to the first TCP Reset I want to talk about. This is one we get a lot from people who just aren’t used to looking at network traffic and think any TCP Reset must be bad, but this is actually expected behavior.

Starting with Windows 2000, the operating system will prefer to use port 445 for SMB instead of port 139. In this process, the client node will send two TCP Syn packets, one with a destination port of 445 and one with a destination port of 139. The specifics of this are beyond the scope of this blog, but the main reason we do both is to allow for backward compatibility. Assuming the server node is listening on both ports 139 and 445 it will respond with an Ack, Syn packet for both ports 139 and 445. The client will then send an Ack on the port it prefers and reset the other port, as shown in the following example.

Ack, Reset

Next is the Ack Reset in response to a Syn. An Ack Reset sent in response to a Syn frame is sent to acknowledge the receipt of the frame but then to let the client know that the server cannot allow the connection on that port. Among the reasons for the Ack, Reset are:

1. The node being connected to is not listening on the port the client node is trying to connect to.
2. There is some reason that the server node cannot complete the connection on that port. For example, the server is out of resources and so cannot allocate the needed resources to allow the connection.

Note: Devices such as firewalls are designed not to return an Ack Reset if they are not actively listening on a port, so the Syn frame will be silently discarded. This is for security reasons.

TCP Reset due to no response

The next reset is a TCP reset that happens when a network frame is sent six times (this would be the original frame plus five retransmits of the frame) without a response. As a result, the sending node resets the connection. This is assuming that we have an established connection after the three way handshake. The number of retransmits before the reset is configurable, but the default is five.

Note: The max number of retransmits for the Syn frame when establishing the connection is 2 by default but can be controlled by the TCPMaxConnectRetransmission registry key.

There are some very important factors to remember here and it is easy for a novice to miss this or get confused and assume TCP has reset the connection when it has not. One thing to look at is the number of retransmits. In this situation, the sender will send a frame and not receive an Ack for that frame, so TCP will go into the normal retransmit behavior, each time not receiving an Ack for that frame. After the packet is retransmitted for the fifth time, the sender waits for a set amount of time for the Ack frame. When it still does not receive the Ack, it then sends a reset for the connection. The assumption is that there is a problem either with the network between the nodes or the node the Ack is being sent to, which means the connection is no longer valid. Some things to watch out for:

1. This has to be the same packet, not just five retransmitted packets. It is the same packet retransmitted five times.
2. It doesn’t matter if other frames have been sent from the sending node and Acknowledged beyond the frame that is being retransmitted.
3. A late Acknowledgement won’t cause this. A late Acknowledgement occurs when the Retransmit Time Out (RTO) has expired before the Acknowledgement of a frame is sent so that the frame is retransmitted and then Acknowledgement for that frame is received.

Application Reset

This situation also generates a lot of calls and, unfortunately, is determined typically by process of elimination. In other words, there is no other reason for the reset so it must have come from the application. I hate saying that, but that really is the answer. If we look at the network traffic and see no reason for TCP itself to have sent the reset, such as the other examples above, then it must have been sent from the application. As I mentioned in the first paragraph, this is perfectly legitimate and my even be desirable. This is a common practice in an application that is making a large number of short-lived TCP connections. Such an application can cause port exhaustion on the server due to so many ports being in a Time Wait state. However, application developers need to understand why the Time Wait state exists before just resetting all connections.

Note: It is possible to look at the code for an application and see if it is performing a Winsock function close(socket). If this is done on a connection where data has been set, then this will generate the Reset. You can also see this in Winsock logging. If this function is called on a TCP connection where only the Three Way Handshake has been completed, but no data has been sent, it will result in the graceful close of the connection using Fin frames.

Another possibility, which is seen less often, happens when some other process on the destination node has grabbed the port. Although rare, this generally will happen when a system is booted up with two applications that both want to listen on the same port.

For advanced users and network Admins

"It Came From the Network" sounds like a bad B movie title. But this actually can happen and can be a pain to track down if you don’t have a good understanding of why resets can occur. What happens is that there is some device on the network, such as a router or firewall, that is actually resetting the connection. This can be confusing because the source and destination IP Addresses are for the sending and receiving nodes and not for the device in the middle. Really the only way to troubleshoot this particular reset behavior is to have a trace from the source and destination nodes. What you will see in the network capture is that the reset that was received by one node is not in the capture of the node that was supposed to have sent it. There are various reasons that these resets can happen and I could write another blog post just on this topic, but what is important to understand is that this is possible. Also, you will often see in my blog posts where I emphasize the importance of having both the source and destination network captures when trying to troubleshoot an issue. This is one of the many examples of why that is.

Another interesting thing that can happen is that the device in the middle can reset the connection on both the client and server nodes. Let’s say we have a TCP connection setup between two nodes. Source IP 10.10.10.20, Destination IP 10.10.10.30, with a connection established between TCP ports 2301 and 445. What we will see is a reset packet sent to 10.10.10.20 for the destination port 2301 and another reset sent to 10.10.10.30 destination port 445.

Port re-use

If an application attempts to reuse a port that is in Time Wait, this may result in a Reset. Just to be clear, this is when a client and server have an existing connection which goes through the graceful close process and ends up in Time Wait. The same client then attempts to re-use the same port pair by sending a Syn frame with the same source and destination port. According to RFC 1122, this should be allowed and I have seen it work. This should be done with caution, keeping in mind that there are reasons for a port to remain in Time Wait. The caveat for this is that the Sequence number in the Syn frame, sent to establish the new connection using the existing connection, must be greater than the sequence number in the last frame of the previous connection. If it is not, then this will result in a reset.

In Summary

TCP Resets are a good thing. They are a useful tool, and also without them we could end up with all sorts of problems when TCP runs into connectivity issues on the network. Remember that Resets can be initiated by both the networking stack as well as an application. Just because there are retransmitted packets does not mean that the connection will automatically be reset. It is important to examine the frames and understand why the retransmits are occurring.