Why Wireshark for Packet Loss
Ping tells you that loss is happening. Wireshark tells you exactly which connections are affected, which layer the loss is occurring at, and whether TCP is recovering cleanly or spiraling into retransmission storms. When a user says "the internet feels slow" and ping looks fine, Wireshark captures often reveal a specific application or TCP stream dropping packets at a rate that ping would never catch because ping uses ICMP, not TCP.
You do not need to be a network engineer to use Wireshark for basic packet loss detection. The Expert Information tool and a handful of display filters do most of the heavy lifting. The key is knowing where to look.
Starting a Capture
Open Wireshark and select the correct interface. On most home computers, this is your active Ethernet adapter or Wi-Fi adapter — look for the one with the moving activity graph on the start screen. Click it to start capturing. Reproduce the problem (open the application that is slow, make the video call, start the game). After 2–5 minutes, stop the capture by pressing the red square button.
If you are capturing Wi-Fi on macOS, use the Wi-Fi adapter in monitor mode — hold Option and click the Wi-Fi menu bar icon, then click "Open Wireless Diagnostics," and from that menu select Window → Sniffer. That gives you a more complete capture than Wireshark directly on macOS Wi-Fi interfaces. On Windows, Wireshark captures Wi-Fi traffic normally.
Display Filters That Find Packet Loss
Once you have a capture, these display filters isolate the packets that indicate retransmissions and loss:
| Display Filter | What It Shows | When It Appears |
|---|---|---|
tcp.analysis.retransmission | TCP segments being resent after no acknowledgment | The receiver never confirmed the original — classic packet loss |
tcp.analysis.fast_retransmission | Fast retransmission triggered by duplicate ACKs | 3 duplicate ACKs received — sender knows a packet was lost quickly |
tcp.analysis.duplicate_ack | The receiver sending repeated acknowledgments | Tells the sender "I got up to this sequence number; where is the next one?" |
tcp.analysis.lost_segment | Wireshark detected a gap in sequence numbers | A packet in the stream is missing from the capture |
tcp.analysis.out_of_order | Packets arriving in wrong sequence | Common on Wi-Fi or congested paths; can trigger false retransmissions |
The most useful combined filter is:
tcp.analysis.retransmission || tcp.analysis.fast_retransmission || tcp.analysis.lost_segmentIf this filter returns many results during a short capture, you have meaningful TCP-level packet loss in the captured traffic.
Using Expert Information
Wireshark's Expert Information panel (Analyze menu → Expert Information) categorizes problems automatically. Look for entries in the Warnings and Errors columns. The most relevant categories for packet loss are:
- TCP Previous segment not captured — a gap in sequence numbers; a packet is missing
- TCP Retransmission — explicit resend of a segment
- TCP Fast Retransmission — rapid resend after duplicate ACKs
- TCP Spurious Retransmission — a packet resent that was already received; can indicate timing problems
A healthy capture will have zero or near-zero warnings in these categories. A capture during a problematic session that shows hundreds of retransmissions tells you definitively that data is being lost and TCP is working hard to recover it.
IO Graphs for Loss Over Time
Statistics → IO Graph shows traffic volume over time. Add a second line using the display filter tcp.analysis.retransmission in a different color. When you see the retransmission line spike at the same moment the user noticed a problem, you have captured the event. This is the graph to screenshot and send to your ISP's tier-2 support — it shows the time, the duration, and the volume of retransmissions during the outage.
TCP Stream Graphs
For a specific slow TCP session, click on any packet from that session, then go to Statistics → TCP Stream Graph → Time-Sequence Graph (Stevens). This shows the sequence number advancement over time. A healthy download looks like a straight diagonal line going up. Packet loss appears as flat spots (waiting for retransmission) or backward steps (resent segments). A capture showing regular flat spots every few seconds confirms retransmission-induced throughput throttling.
Wireshark vs Ping: When to Use Each
Ping is faster and works well for general packet loss detection across the full network path. Wireshark is the right tool when you need to answer a more specific question: which application is affected, which TCP stream is dropping packets, or whether the loss is happening before or after a specific device on your LAN. Wireshark only sees traffic that reaches your machine — it cannot show loss happening between your router and the ISP unless you capture at the router. For that, MTR or your modem's signal level page is more useful.
Frequently Asked Questions
Wireshark shows zero retransmissions but my connection feels bad. Why?
Wireshark only captures what reaches your network adapter. If packet loss is happening between your router and the ISP's network, those packets never arrive at your machine — there is nothing for Wireshark to see. In this case, MTR (which traces hop-by-hop) or your modem's signal/event log will show the problem. Also, UDP-based traffic (VoIP, gaming, WebRTC video) does not retransmit — Wireshark will not show retransmissions for UDP packet loss; you would instead look for RTP sequence number gaps.
How do I filter for a specific application's traffic?
If you know the destination IP address or port, use a filter like ip.addr == 1.2.3.4 && tcp.analysis.retransmission. For specific application ports, filter by port: tcp.port == 443 && tcp.analysis.retransmission for HTTPS. Right-clicking any packet and selecting "Follow TCP Stream" isolates all packets for that specific connection so you can see the retransmission pattern in context.
How large will the capture file get?
A 5-minute capture on a 100 Mbps connection transferring actual data can produce a very large file — 100 MB or more. For diagnostic purposes, use a capture filter to limit what is recorded. For packet loss analysis, you can capture only TCP traffic using the BPF filter tcp entered in the capture options before starting. Alternatively, use ring buffers (Capture Options → Output) to keep only the last N megabytes, which discards older packets and keeps file size manageable during long monitoring sessions.
Can I use Wireshark on a phone or tablet?
Not directly, but on Android you can use tools like PCAPdroid (no root required) or tcpdump (with root) to capture traffic and then open the resulting .pcap file in Wireshark on a computer. iOS does not allow third-party packet capture apps — you can use Apple's Remote Virtual Interface (rvictl command on macOS) to capture an iPhone's traffic through a Mac running Wireshark, but it requires a macOS machine and a USB connection.