Articles

TCP Analysis in Wireshark: Decode Streams and Errors (2026)

April 6, 2026 7 min read

Wireshark can decode TCP streams, letting you see the actual conversation between two hosts, but it’s often more useful for finding what went wrong.

Let’s see what a simple HTTP GET request looks like in Wireshark. First, capture some traffic. I’ll use tcpdump on a Linux machine to capture traffic going to port 80, and then I’ll use curl to fetch a webpage.

sudo tcpdump -i eth0 -w http_capture.pcap port 80
# In another terminal:
curl http://example.com

Now, open http_capture.pcap in Wireshark. Filter for HTTP traffic: http. You’ll see a bunch of packets. To see the actual HTTP conversation, right-click on any GET / HTTP/1.1 packet and select "Follow" > "TCP Stream."

A new window pops up showing the data exchanged. You’ll see the GET / HTTP/1.1 request from your curl client and the HTTP/1.1 200 OK response from example.com, including the HTML content. This is the "happy path."

But Wireshark truly shines when things go wrong. Let’s look at some common TCP errors.

TCP Retransmissions

This is the most common TCP error you’ll see. A retransmission happens when the sender doesn’t receive an acknowledgment (ACK) for a segment within a certain timeout period. The sender, assuming the segment was lost, sends it again.

Diagnosis: Filter for tcp.analysis.retransmission. You’ll see packets marked as "TCP Retransmission."

Common Causes & Fixes:

  1. Network Congestion: The most frequent culprit. Packets are dropped because the network path is overloaded.

    • Diagnosis: Look for a high rate of retransmissions, especially during periods of high network utilization. Check interface statistics on routers and switches for dropped packets.
    • Fix: Reduce network traffic. Implement Quality of Service (QoS) to prioritize critical traffic. For a specific host, you might need to investigate if it’s sending too much data too fast, though this is rare for legitimate traffic.
    • Why it works: Less traffic means fewer packets competing for limited bandwidth, reducing the chance of drops and thus retransmissions.

  2. Packet Loss on a Specific Link: A faulty cable, a misconfigured switch port, or a failing network interface card can cause intermittent packet loss.

    • Diagnosis: If retransmissions are consistently happening between two specific hosts, and you’ve ruled out general congestion, examine the physical path between them. Check interface error counters (ifconfig or ip -s link show <interface> on Linux, show interface on Cisco).
    • Fix: Replace faulty hardware (cables, NICs). Reconfigure switch ports if necessary.
    • Why it works: Eliminating the source of physical packet loss prevents segments from being dropped before they even reach their destination.

  3. Incorrect TCP Window Size: The receiver’s advertised window size might be too small, leading the sender to believe data is lost when it’s just waiting for the receiver to process it and open the window.

    • Diagnosis: In Wireshark, look at the "TCP Window size value" in the packet details for both directions. If the receiver’s window is consistently small and the sender is retransmitting, this is a possibility.
    • Fix: For Linux, increase the TCP receive buffer sizes:
      sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
      For Windows, this is often managed by auto-tuning. If manually configured, adjust Receive Window Auto-Tuning Level to normal or highlyrestricted via netsh interface tcp set global.
    • Why it works: A larger receive window allows the sender to transmit more data before needing an acknowledgment, smoothing out the flow and reducing the likelihood of timeouts due to buffer limitations.

  4. Firewall/IPS Dropping Packets: Stateful firewalls or Intrusion Prevention Systems might incorrectly identify legitimate traffic as malicious and drop packets.

    • Diagnosis: Check firewall logs and IPS alerts. If retransmissions coincide with security device logs showing dropped packets for the involved hosts, this is a strong indicator.
    • Fix: Tune firewall/IPS rules. Add exceptions for the specific traffic if it’s deemed safe.
    • Why it works: Preventing the firewall or IPS from interfering with or dropping valid TCP segments ensures they reach their destination.

  5. Asymmetric Routing: If traffic takes different paths in each direction, and one path has issues (e.g., packet loss, high latency), it can lead to retransmissions. The ACK might not reach the sender because it’s coming back via a different, problematic route.

    • Diagnosis: Use traceroute (or tracert on Windows) from both source and destination to see the paths taken. Compare them.
    • Fix: Reconfigure routing to ensure traffic between two hosts takes the same path in both directions, or at least paths with similar quality.
    • Why it works: Ensures that acknowledgments travel back along a reliable path, allowing the sender to confirm receipt of segments promptly.

TCP Dup ACK (Duplicate Acknowledgments)

A Dup ACK is sent by the receiver when it receives a segment out of order. It acknowledges the last in-order segment it received. A series of Dup ACKs often indicates that a segment was lost. The sender uses three Dup ACKs as a trigger for "Fast Retransmit," sending the missing segment without waiting for a retransmission timeout.

Diagnosis: Filter for tcp.analysis.duplicate_ack.

Common Causes & Fixes:

The causes are largely the same as for TCP Retransmissions, as Dup ACKs are a symptom of the same underlying issues (packet loss, reordering).

  1. Packet Loss: A segment is lost, and subsequent segments arrive out of order.

    • Diagnosis: See TCP Retransmissions. Look for a cluster of Dup ACKs followed by a retransmission of the missing segment.
    • Fix: Address the source of packet loss (network congestion, faulty hardware, etc.).
    • Why it works: Preventing segment loss ensures segments arrive in order, so the receiver doesn’t need to send Dup ACKs.

  2. Packet Reordering: Segments arrive at the destination out of order, even if none were lost. This can happen due to multiple network paths with different latencies.

    • Diagnosis: You’ll see Dup ACKs, but the missing segment might eventually arrive later, in order. The retransmission might not even be necessary if the out-of-order segment arrives before the timeout.
    • Fix: Reroute traffic to use more consistent paths, or ensure that path diversity isn’t excessive.
    • Why it works: If packets maintain their original order, the receiver will see them sequentially and won’t generate duplicate ACKs.

TCP Zero Window

This occurs when the receiver’s TCP receive buffer is full, and it advertises a window size of 0. The sender must stop sending data until the receiver advertises a non-zero window.

Diagnosis: Filter for tcp.analysis.zero_window. You’ll see packets with "TCP ZeroWindow" in the Info column.

Common Causes & Fixes:

  1. Slow Application Receiver: The application on the receiving end isn’t consuming data from the TCP buffer fast enough.

    • Diagnosis: Check the CPU and I/O load on the receiving server. Monitor the application’s processing rate.
    • Fix: Optimize the receiving application’s performance. Increase the application’s buffer sizes if possible.
    • Why it works: A faster application drains the TCP buffer more quickly, allowing the receiver to advertise a non-zero window sooner.

  2. Insufficient Receiver Buffer Size: The system’s TCP receive buffers are too small for the data rate.

    • Diagnosis: See the "Incorrect TCP Window Size" diagnosis under Retransmissions. If you see frequent zero windows and the system’s net.ipv4.tcp_rmem limits are low, this is likely the cause.
    • Fix: Increase the system’s TCP receive buffer sizes (see Fix for Incorrect TCP Window Size under Retransmissions).
    • Why it works: Larger buffers can hold more data, providing more time for the application to process it before the buffer fills up and advertises a zero window.

  3. Network Congestion (Indirectly): While not a direct cause, severe congestion can lead to ACKs being delayed, making the receiver’s buffer fill up faster from the sender’s perspective, which can then lead to a zero window advertisement.

    • Diagnosis: Correlate zero window events with high retransmission rates or general network saturation.
    • Fix: Address general network congestion.
    • Why it works: Reducing overall network load ensures timely delivery of ACKs, preventing the receiver’s buffer from appearing full to the sender.

After fixing these, the next error you’ll likely encounter is TCP Keep-Alive issues if connections are left idle for too long.

More Deep Dives in Tcp

Want structured learning?

Take the full Tcp course →