This post will try to explain the most common TCP issues I’ve run into and probably most of you, too. And these are TCP retransmissions, TCP duplicates, TCP zero window, and TCP resets.
TCP retransmissions
After sending a packet of data, the sender will start a retransmission timer of variable length. If it does not receive an acknowledgment before the timer expires, the sender will assume the segment has been lost and will retransmit it. The TCP retransmission mechanism ensures that data is reliably sent from end to end. If retransmissions are detected in a TCP connection, it is logical to assume that packet loss has occurred.
This can be caused by many things: packet errors, excessive buffering, and traffic bursts.
A few retransmissions are expected.
If you want to filter on TCP transmissions use this Wireshark filter:
“tcp.analysis.retransmission”
TCP duplicates
Most packet analyzers will indicate a duplicate acknowledgment condition when two ACK packets are detected with the same ACK numbers.
Typically, duplicate acknowledgments mean that one or more packets have been lost in the stream and the connection is attempting to recover. They are a common symptom of packet loss.
In most cases, once the sender receives three duplicate acknowledgments, it will immediately retransmit the missing packet instead of waiting for a timer to expire. These are called fast retransmissions.
Connections with more latency between the client and server will typically have more duplicate acknowledgment packets when a segment is lost.
If you want to filter on TCP duplicates use this Wireshark filter:
“tcp.analysis.duplicate_ack_frame”
TCP zero window
TCP Zero Window is when the Window size in a machine remains at zero for a specified amount of time. This means that the machine is not able to receive further information at the moment, and the TCP transmission should be halted until it can process the information that is pending in its buffer.
It could be that the machine is running too many processes at that moment, and its processor is maxed. Or it could be that there is an error in the TCP receiver. Also, it might be that the application does not pick up the packets in a timely fashion from the TCP buffer.
If the recipient should empty its receive buffers at all (in other words, the application makes even a partial pickup), it will announce the new “space available” with a TCP Window Update.
If you want to filter on TCP ZeroWindow use this Wireshark filter:
“tcp.analysis.zero_window”
TCP resets
TCP resets are used to refuse an incoming connection or to restart a connection.
The receiver of an RST segment should also consider the possibility that the application protocol client at the other end was abruptly terminated and did not have a chance to process the data that was sent to it.
Other important things to know are:
- You issue an SYN if the server replies RST: it means that theย portย is closed!
- You issue an SYN, if the server does not reply, or replies with an ICMP error: it means that theย portย isย filtered. Likely an IDS / stateful firewall blocking your request.
If you want to filter on the TCP RST flag use this Wireshark filter:
“tcp.flags.reset !=0”
