Wireshark Expert Information: Decode Warnings and Errors (2026)

The Wireshark Expert Information pane is where the tool flags potential issues with your packet capture, acting as an early warning system before you even start digging into individual packets.

Let’s see it in action. Imagine you’ve captured traffic on a network and opened the capture file. You’ll see a new pane at the bottom of the Wireshark window, by default. This pane, "Expert Information," is categorized by severity: "Messages," "Notes," "Warnings," and "Errors."

Here’s what a typical "Error" might look like:

TCP Duplicate ACK received, 0.000000, Server -> Client

And a "Warning":

TCP Retransmission, 0.000000, Client -> Server

This isn’t just Wireshark telling you something might be wrong; it’s pointing out specific protocol violations or anomalies that indicate a problem on the network or with the communicating devices.

Understanding the Categories

• Messages: These are the least severe, often indicating interesting but not necessarily problematic events. Think of them as "FYI" notifications.
• Notes: Slightly more significant than messages, notes might highlight unusual but valid protocol behavior.
• Warnings: These are where things start to get interesting. Warnings typically point to potential performance issues or deviations from ideal network behavior. Retransmissions, duplicate ACKs, and out-of-order segments often fall here.
• Errors: The most critical category. Errors indicate definitive protocol violations or packet loss that are actively hindering communication. This could be a TCP connection reset, an ICMP Destination Unreachable, or a malformed packet.

Decoding Common Expert Information Items

Let’s dive into some of the most common warnings and errors you’ll encounter and what they mean.

TCP Retransmission

What it looks like: TCP Retransmission, [time], [source] -> [destination]

What actually broke: A TCP sender (Client or Server) sent a segment of data, but it never received an acknowledgment (ACK) from the receiver within its retransmission timeout period. The sender then assumed the segment was lost and resent it. This indicates packet loss between the sender and receiver, or a delay in the ACK making it back.

Common Causes & Fixes:

1. Network Congestion: The most frequent culprit. Routers or switches along the path are overloaded, dropping packets.

   • Diagnosis: Look for a high volume of retransmissions, especially during periods of heavy traffic. Check interface utilization on routers and switches.
   • Fix: Identify the bottleneck. This might involve upgrading link speeds, optimizing routing, or implementing Quality of Service (QoS) to prioritize critical traffic. If it’s a specific application, optimize that application’s traffic patterns.
   • Why it works: Reducing congestion means fewer packets are dropped, so the sender doesn’t need to retransmit.

2. Firewall/IPS Dropping Packets: A security device might be mistakenly identifying legitimate traffic as malicious and dropping it.

   • Diagnosis: Correlate retransmissions with events on firewalls or Intrusion Prevention Systems (IPS). Check firewall logs for dropped packets matching the source/destination IP and port.
   • Fix: Adjust firewall rules or IPS signatures to allow the specific traffic. For example, if a specific port is being blocked, add an explicit allow rule.
   • Why it works: The firewall stops dropping the packets, allowing them to reach their destination and enabling timely ACKs.

3. Faulty Network Hardware: A failing NIC, cable, or switch port can introduce errors and packet loss.

   • Diagnosis: Check interface error counters (rx_errors, tx_errors, CRC errors) on switches and NICs. Look for intermittent connectivity issues.
   • Fix: Replace the faulty hardware. This could be a bad Ethernet cable, a failing switch port, or a malfunctioning Network Interface Card (NIC) on a server.
   • Why it works: New, functional hardware doesn’t corrupt or drop packets, ensuring reliable delivery.

4. High Latency/Jitter: While less common for causing outright retransmissions (more for performance degradation), extreme latency or jitter can push the retransmission timer too close to the edge.

   • Diagnosis: Measure round-trip time (RTT) between the client and server using ping or traceroute. Look for significant variations in RTT.
   • Fix: Optimize network paths to reduce hops and distance. Ensure proper network design and avoid routing traffic over excessively long or congested links.
   • Why it works: Lower and more consistent latency ensures ACKs arrive before the retransmission timer expires.

5. Application-Level Issues: Some applications might have poorly implemented TCP stacks or be sending data too rapidly for the network to handle.

   • Diagnosis: Isolate the retransmissions to traffic from a specific application. Check application logs for errors.
   • Fix: Tune application settings to send data more slowly or in smaller bursts. Update the application if it’s a known bug.
   • Why it works: The application sends data at a rate that the network can reliably support.

TCP Duplicate ACK Received

What it looks like: TCP Duplicate ACK received, [time], [source] -> [destination]

What actually broke: A TCP receiver has received an ACK that it has already sent. This typically happens when the receiver gets a segment of data out of order, or when a segment it did receive was lost and the sender retransmitted it. The duplicate ACK signals to the sender that the receiver is expecting a specific sequence number.

Common Causes & Fixes:

1. Packet Loss: This is the primary cause. A data segment was lost in transit, and the receiver is repeatedly acknowledging the last in-order segment it received.

   • Diagnosis: Often occurs in conjunction with TCP Retransmissions. Wireshark will show a retransmitted segment shortly after a series of duplicate ACKs.
   • Fix: Address the underlying packet loss (see "TCP Retransmission" causes above).
   • Why it works: Once the lost segment is successfully delivered (via retransmission), the receiver will get the next expected segment, and the duplicate ACKs will cease.

2. Out-of-Order Delivery: Network devices (like certain load balancers or routers using ECMP - Equal-Cost Multi-Path) might send subsequent packets via a different path, causing them to arrive out of sequence.

   • Diagnosis: Look for a pattern where duplicate ACKs are immediately followed by segments that are not the one being acknowledged. Wireshark might show segments arriving with sequence numbers lower than expected.
   • Fix: Reconfigure load balancers or routing to ensure packets for a single TCP flow follow the same path. This often involves using "flow-based" or "session-based" load balancing.
   • Why it works: Ensuring in-order delivery means the receiver gets segments sequentially, so it only needs to send one ACK for each in-order segment.

3. Network Latency Spikes: A sudden, significant increase in latency for a specific packet can cause it to arrive late, triggering duplicate ACKs if earlier packets were already acknowledged.

   • Diagnosis: Similar to packet loss, but the "lost" packet eventually arrives. Look for a late-arriving segment corresponding to the sequence number the duplicate ACKs were asking for.
   • Fix: Address network latency issues (see "TCP Retransmission" cause #4).
   • Why it works: Consistent, low latency ensures packets arrive in a timely manner, preventing the out-of-order or late-packet scenario.

TCP Window Full

What it looks like: TCP Window Full, [time], [source] -> [destination]

What actually broke: The TCP receiver’s receive window is full, meaning it has no buffer space to accept more incoming data. The sender is trying to send data, but the receiver is advertising a window size of 0 in its ACKs. This effectively pauses the data flow until the receiver has processed some data and freed up buffer space.

Common Causes & Fixes:

1. Application Not Reading Data Fast Enough: The most common reason. The application on the receiving end isn’t consuming the data from the TCP receive buffer quickly enough.

   • Diagnosis: Wireshark will show the receiver advertising a TCP window size of 0. Check the application’s performance and resource utilization (CPU, I/O) on the receiving host.
   • Fix: Optimize the application’s processing logic. Increase the application’s buffer sizes if possible, or ensure it’s not blocked by other processes.
   • Why it works: The application reads data from the buffer faster, making space for new incoming data.

2. Insufficient Receiver Buffer Size: The operating system’s TCP receive buffer for that connection might be too small.

   • Diagnosis: Even if the application is processing data, if the OS buffers are small, they can fill up quickly. Check netstat -s or /proc/net/snmp for TCP buffer statistics.
   • Fix: Increase the TCP receive window size for the host. This is typically done via sysctl settings (e.g., net.ipv4.tcp_rmem on Linux) or registry settings on Windows. You might need to set net.core.rmem_max and net.ipv4.tcp_rmem. For example, on Linux: sudo sysctl -w net.ipv4.tcp_rmem='4096 87380 6291456'
   • Why it works: Larger buffers allow the receiver to accept more data before it needs to be processed by the application, preventing the window from closing.

3. Network Latency: High latency can exacerbate the problem. Data sits in the buffers for longer, increasing the chance they’ll fill up before the application can clear them.

   • Diagnosis: High RTT between client and server.
   • Fix: Reduce network latency.
   • Why it works: Faster ACKs and data flow reduce the time buffers are occupied.

The next expert information you’ll likely encounter after fixing these is related to TCP connection establishment or teardown issues, such as "TCP Spurious Retransmission" (where a segment was thought lost but actually arrived late) or "TCP Reset" (indicating a connection was abruptly terminated).