Wireshark and the most common TCP issues

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, 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, traffic bursts.

Above you can see that after more than 1s a frame get’s sent again.

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 acknowledgements mean that one or more packets has 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 client and server will typically have more duplicate acknowledgement 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 it’s 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 pickup 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.

You can see above that after a TCP ZeroWIndow the receiver sends a Window Update signaling it can now receive more data

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 a 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 a SYN, if the server replies RST : it means that the port is close !
  • You issue a SYN, if the server does not reply, or replies with ICMP error : it means that the port is filtered. Likely an IDS / statefull firewall block your request.

If you want to filter on TCP RST flag use this wireshark filter:
“tcp.flags.reset !=0”

About the author

Mihai is a Network Aficionado with more than 10 years experience