Below is a great TCP Analysis Flags Cheat Sheet for Wireshark. These are essentially Display Filters. They are all included in our TCP troubleshooting profile you can find here.
| Analysis Flags/Display filter | Trigger | Impact/Meaning/Notes |
| tcp.analysis.ack_lost_segment | A segment that is not in the trace has been acknowledged | Indicates that not all packets have been recorded or a route has been flapped |
| tcp.analysis.duplicate_ack | The receiver tries to trigger Fast Retransmissions | One or more packets are missing (usually due to loss), and the receiver keeps acknowledging the last in-order byte. TCP fast retransmit is triggered after 3 duplicate ACKs — this helps recover from loss without waiting for a timeout. Duplicate ACKs also occur due to out-of-order delivery. Case dependent (few usually no problem) |
| tcp.analysis.keep_alive | The sender sends a Keep Alive | Just keeping the TCP session in place. Good, the connection continues |
| tcp.analysis.window_update | The receiver sends a Window Update | Good, the sender is allowed to send again, or bad in that a window could be closing slowing things down |
| tcp.analysis.window_full | The receive window is completely used by bytes in flight. | Can be bad for performance. Processing overload on the system that sent this flag? |
| tcp.analysis.zero_window | The receive window is 0, the sender paused, and is not allowed to send anymore until window is opened | Indication of performance problem or transition from a fast to slow link, or buffers are full on the system that sent this. Zero window is a form of flow control: the receiver is asking the sender to pause transmission. Persistent zero window conditions may indicate: A slow or overloaded receiving application. A network bottleneck or performance issue. Misconfigured TCP window scaling. It’s not an error unless it persists for a long time. |
| tcp.analysis.spurious_retransmission | Retransmission of a packet for which there is already a Seq # in the trace | If the sender sends too many, this may mean congestion |
| tcp.analysis.lost_segment | Segment lost, either really or just not recorded in the trace | Wireshark is detecting probable lost packets. Case dependent (few usually no problem) |
| tcp.analysis.retransmission or tcp.analysis.fast_retransmission | Not seen Seq # was retransmitted | Retransmissions mean data was lost. Case dependent (few usually no problem) |
| tcp.analysis.out_of_order | Packets are in the wrong Seq # order | Few out of orders are no problem, if the out of orders become larger than the receive window, there will be problems |
| tcp.analysis.reused_ports | A port pair is reused | Case dependent, if ports are used too often it indicates port exhaustion. |
| tcp.analysis.ack_rtt > 1.0 | Long RTT time for ACKs | Time should be adjusted as necessary |
| tcp.window_size_scalefactor==-2 | No window scaling is used | Here are some reasons: No Window Scaling Option in SYN TCP window scaling is negotiated during the initial three-way handshake. If the client does not include the Window Scale option in its SYN packet, scaling will not be used. Server Does Not Acknowledge Window Scaling Even if the client offers the option, the server must echo it back in the SYN-ACK. If the server does not support or does not include the option in the SYN-ACK, it is disabled. Operating System Defaults or Configuration Some OSes or network stacks disable window scaling by default or limit it unless explicitly enabled: On Linux: /proc/sys/net/ipv4/tcp_window_scalingOn Windows: can depend on TCP Auto-Tuning levels. Middlebox Interference (Firewall, NAT, etc.) Some poorly designed firewalls or NAT devices strip TCP options, including window scaling, from packets. This results in the server never seeing the option, thus not negotiating it. Both Sides Have Small Buffers If both sender and receiver advertise small window sizes that do not exceed 65,535 bytes, scaling is not needed. Example: A legacy system or low-throughput connection. |
| tcp.flags.reset == 1 and tcp.seq == 1 | Immediate reset | Requires investigation. Typically indicates that the connection is being refused or interrupted before it can be established. Here are some causes: No Application Listening on the Port The destination host is reachable, but no service is bound to the requested TCP port. Example: Connecting to port 80 when no web server is running. Firewall or Security Policy A firewall (host-based or network) explicitly rejects the connection with a TCP RST. This can be done to avoid timeouts or as part of a security policy (e.g., IDS/IPS behavior). TCP Wrapper or Host-Level ACLs On Unix/Linux, services protected by tcpd (TCP wrappers) or iptables may send a RST if the client IP is not allowed.Incorrect Routing or Asymmetric Path If the SYN arrives at the host, but the reply path is broken or redirected, the host may send an RST if it detects invalid state or routing issues. Connection to a Closed Port via Load Balancer If you’re hitting a load balancer or proxy, and the backend is down or refuses the connection, a RST may be generated. Host Actively Refusing Connections Some hosts are configured to immediately reject connections to unused ports rather than silently dropping them. Spoofed or Malformed SYN If the host detects invalid headers or options in the SYN (e.g., invalid TCP options), it may respond with a RST. Middlebox Interference Some security appliances or NAT devices send RSTs on behalf of endpoints for traffic deemed malicious or non-compliant. |
| tcp.window_size == 0 && tcp.flags.reset == 0 | Zero Window (without resets) | This typically identifies TCP Zero Window conditions where: The receiver is temporarily unable to accept more data (its receive buffer is full). But the connection is still open — it’s not being reset (no RST). |
| tcp.segment.error | TCP segment error | Common causes of segment errors: Packet Corruption (Layer 1/2) Caused by: Faulty cabling, electrical interference, damaged NICs, or bad hardware. Symptoms: Checksum errors, malformed packets. 2. Packet Loss or Reordering Caused by: Network congestion, overloaded routers/switches, or poor Wi-Fi signal. Symptoms: Out-of-order segments, retransmissions, duplicate ACKs. 3. Retransmissions Caused by: Dropped packets due to congestion, long RTTs, or firewall dropping segments. Symptoms: Repeated segments with same sequence number. 4. MSS or MTU Mismatch Caused by: Path MTU discovery failures or misconfigured MSS clamp. Symptoms: Fragmentation issues, dropped large packets, black-hole routing. 5. Window Size Problems Caused by: Receiver advertising small window or zero window due to buffer exhaustion. Symptoms: Zero Window updates, stalled transfer, slow performance. 6. TCP Option Errors Caused by: Broken or stripped TCP options (e.g., Window Scale, SACK) by middleboxes. Symptoms: Handshake failures, inconsistent behavior between segments. 7. Checksum Errors Caused by: Hardware checksum offload mismatch (e.g., seen in Wireshark but not real). Symptoms: False positives in packet captures, often benign if due to offloading. 8. Protocol Misbehavior or Bugs Caused by: Misconfigured TCP stacks, mismatched protocol versions, or rare edge cases. Symptoms: Invalid sequence numbers, resets, or segments that violate TCP state machine. 9. Firewall/IDS/IPS Interference Caused by: Devices that alter, drop, or inject TCP segments for inspection or protection. Symptoms: Unexpected resets, mid-stream packet drops, or malformed segments. |
| tcp.flags.syn == 1 and tcp.hdr_len < 28 | TCP handshake without SACK and MSS | Common causes: Middlebox Stripping TCP Options Firewalls, NATs, or proxies remove TCP options from SYN packets. Often seen in overly aggressive or misconfigured security devices. Result: Server never sees or responds with those options. 2. Operating System or Stack Configuration TCP options can be disabled manually via system settings: Linux: /proc/sys/net/ipv4/tcp_sack = 0MSS option might be suppressed by a custom stack or API setting. Embedded or minimal systems (e.g., IoT devices) may not use these options. 3. Use of Raw or Custom TCP Stack Tools like Scapy, hping3, or certain malware/tunnels may craft TCP SYN packets without standard options. Common in security testing or non-standard protocol implementations. 4. Fragmented or Truncated Packets If SYN packets are fragmented or truncated (e.g., due to MTU/misrouting), options at the end might be lost or unreadable. 5. Virtual Network Interfaces or VPN Tunnels Some VPNs, tunnels, or containers may alter or drop TCP options for encapsulation simplicity or compatibility. 6. Legacy Systems or Compatibility Modes Older systems or connections using strict RFC 793 compatibility may avoid newer options like SACK (RFC 2018) or even MSS. |
| tcp.ack > tcp.options.sack_le and tcp.options.sack.count == 1 | Duplicate SACKs | Common causes: Packet Loss One or more segments are lost, and the receiver sends SACKs for the segments it received after the missing one(s). If the missing segment is not yet retransmitted or recovered, the receiver keeps sending the same SACK blocks with duplicate ACKs. 2. Out-of-Order Delivery Packets arrive out of sequence due to: Parallel paths in the network (multipath routing) Reordering by routers/switches Receiver sends SACKs for out-of-order segments and continues to duplicate the SACK block until the expected in-order segment arrives. 3. Delayed or Dropped Retransmissions If the sender’s retransmission is lost or delayed, the receiver keeps repeating the same SACK block to indicate the segment is still missing. 4. Persistent Reordering or Jitter Common in mobile networks, satellite links, or Wi-Fi where jitter or buffering causes multiple out-of-order segments. 5. Buggy TCP Stack or Misbehaving Middleboxes Rare, but sometimes a faulty implementation on the receiver or a proxy alters or resends incorrect SACKs. |
| tcp.options contains 01:01:01:01 | Many NOPs in the options fields | This filter is generally used when: Looking for malformed or suspicious TCP options. Detecting custom TCP options (e.g., for malware, covert channels, or protocol experiments). Debugging TCP implementations that might be sending invalid options. |
Comments are welcomed below from registered users. You can also leave comments at our Discord server.
If you would like to see more content and articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!