Windows SMB Reset(good part)
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.
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:
- The node being connected to is not listening on the port the client node is trying to connect to.
- 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 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:
- This has to be the same packet, not just five retransmitted packets. It is the same packet retransmitted five times.
- It doesn’t matter if other frames have been sent from the sending node and Acknowledged beyond the frame that is being retransmitted.
- 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.
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.
Reference
Where do resets come from? (No, the stork does not bring them.)