Find Dropped Packets in Wireshark: Step-by-Step

Updated 4 November 2026 · Standard formula, shown below

To find dropped packets in Wireshark, open the “Telephony” menu, select “RTP,” then “Stream Analysis,” and look for the “Packet Loss” column, or use the built-in “Statistics > Capture File Properties” to see the “Dropped Packets” count. Alternatively, apply a display filter like rtp.ssrc and check the “RTP Player” for gaps in sequence numbers. This article explains the different types of packet loss, how to detect them, and how to interpret the results.

What Counts as a Dropped Packet?

In Wireshark, a “dropped packet” can mean two very different things. The first is a packet that was captured by your network interface but was not processed by Wireshark because the capture buffer was full or the CPU was too slow. This is a capture-side drop, and it indicates that your analysis is incomplete. The second is a packet that was sent by a device but never arrived at the capture point, often due to network congestion, faulty hardware, or firewall rules. This is a network-side drop, and it is the real-world loss you are likely investigating. Wireshark itself cannot tell you which type you are seeing unless you check the capture statistics and the protocol-specific loss indicators.

Where to Find the Dropped Packets Count

The most direct way to see if Wireshark itself dropped packets is to look at the bottom-right corner of the main window. You will see a small icon that shows a green or red square. Hover over it to see the exact number of packets dropped during the capture. For a more detailed view, go to Statistics > Capture File Properties. In the “Capture” section, you will see three numbers: “Packets captured,” “Packets displayed,” and “Packets dropped.” If the dropped count is not zero, your capture is incomplete, and you should increase the capture buffer size or use a dedicated capture device.

Using Display Filters to Spot Loss

For network-side loss, you need to look at the protocol layer. The most common protocols with loss detection are TCP and RTP. For TCP, apply the filter tcp.analysis.lost_segment to see packets that Wireshark has flagged as missing. These are gaps in the sequence numbers, which indicate that a packet was not seen. For RTP (real-time audio/video), use rtp.ssrc to isolate a stream, then go to Telephony > RTP > Stream Analysis. This window shows a graph of packet loss and jitter, and the table lists the percentage of lost packets for each stream. A loss of 1% or less is generally acceptable for voice, while more than 5% will cause noticeable audio issues.

How to Interpret the RTP Stream Analysis

The RTP Stream Analysis window is a powerful tool, but it can be overwhelming. The key columns are “Sequence” and “Lost.” The sequence number should increment by one for each packet. If you see a jump from 100 to 105, that means four packets are missing. The “Lost” column shows the cumulative number of missing packets. The graph at the top shows the jitter (variation in delay) and the packet loss over time. A spike in the loss graph corresponds to a moment when packets were dropped. To hear the effect, click “Play” to listen to the audio with the missing packets. This helps you decide if the loss is severe enough to require action.

Common Causes of Packet Drops

Packet drops are rarely random. They usually point to one of several issues. The most common are:

Network congestion: When a router or switch buffer overflows, it drops packets. This often happens during large file transfers or video streaming.
Faulty hardware: A bad cable, a failing network card, or a misconfigured switch can cause intermittent drops.
Firewall rules: A firewall may silently drop packets that do not match its rules, especially ICMP or UDP traffic.
Wi-Fi interference: Wireless networks are prone to drops due to signal attenuation, obstacles, or channel overlap.
CPU overload: If the capturing device is under heavy load, it may not be able to process all packets in time, leading to capture-side drops.

To diagnose, start by checking the capture file properties for capture-side drops. If those are zero, move to the protocol analysis. If you see TCP lost segments, check for congestion. If you see RTP loss, look at the jitter graph to see if it correlates with high network usage.

How to Prevent Capture-Side Drops

Capture-side drops are frustrating because they make your analysis unreliable. Here are steps to minimize them:

Increase the capture buffer size in Capture > Options. The default is often 2 MB, but you can set it to 128 MB or more.
Use a capture filter to only capture the traffic you need. For example, tcp port 443 will only capture HTTPS traffic, reducing the load.
Stop other applications that are using the network or CPU while capturing.
If you are on a high-speed network, consider using a dedicated capture appliance or a network tap.
In Wireshark, go to Capture > Options and enable “Update list of packets in real time” only if you must see packets live; this slows down the capture.

If you still see drops, try capturing to a file directly (not to the screen) by using the “File” option in the capture dialog. Writing to disk is faster than updating the GUI.

Comparing Wireshark with Other Tools

Wireshark is not the only tool for finding dropped packets. tcpdump is a command-line alternative that is lighter and faster, but it lacks the graphical analysis. For high-throughput networks, tools like ntopng or commercial analyzers can handle more packets per second. However, Wireshark’s RTP analysis is unique in its depth. The “RTP Player” allows you to listen to the actual audio, which is invaluable for VoIP troubleshooting. For TCP, you can also use the “Statistics > Flow Graph” to see the sequence numbers and spot retransmissions, which are a sign of lost segments. Wireshark is the best free option for most users, but be aware of its performance limits on very busy links.

Frequently Asked Questions

What does “dropped packets” mean in the status bar?

It means Wireshark’s capture buffer overflowed, and some packets that were received by the network interface were not stored. This is a capture-side loss, not a network loss. Your analysis is incomplete, so you should fix the capture settings and redo the capture.

How can I tell if a packet was dropped on the network?

Look for protocol-specific indicators. For TCP, check for “TCP Analysis Flags” like “Lost Segment” or “Retransmission.” For RTP, use the Stream Analysis tool. A gap in sequence numbers indicates a network drop.

Can I recover dropped packets in Wireshark?

No. Once a packet is dropped, it is gone. You cannot recover it from the capture file. You need to re-capture with better settings or use a different capture point.

Why does Wireshark show duplicate packets?

Duplicates can be caused by capturing on a switch with port mirroring, or by a network loop. They are not the same as drops, but they can confuse analysis. Use the filter tcp.analysis.duplicate_ack to find them.

Is there a way to see packet loss in a live capture?

Yes, the status bar icon updates in real time. Also, you can use Statistics > I/O Graph to plot TCP retransmissions or lost segments over time.

What is a good packet loss percentage?

For VoIP, under 1% is excellent, 1-2% is acceptable, and above 5% is poor. For TCP, any loss is bad because it triggers retransmissions, which slow down the connection. In general, aim for zero loss in a healthy network.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.