When to Use Wireshark
Use Wireshark when ping, traceroute, nslookup, and browser dev tools confirm something is wrong but cannot explain why. Common situations where packet capture adds value:
- DNS queries that appear to succeed but return wrong or slow answers
- TCP connections that open but stall without data flowing
- TLS handshake failures showing as SSL errors in the browser
- Packet loss confirmed by ping that traceroute cannot localize
- Application protocol debugging (HTTP headers, DHCP negotiation, SIP call setup)
Capture interface selection
Wireshark's start screen lists every network interface with a live traffic graph. Pick the one showing activity — Ethernet (eth0, en0) for wired, Wi-Fi (wlan0, en1) for wireless. Promiscuous mode, enabled by default, instructs the NIC to pass all frames it sees to Wireshark rather than only frames addressed to your MAC. On a switched network this captures all traffic to and from your machine — not your neighbors' traffic. On an unmanaged hub or a mirrored switch port, promiscuous mode captures other hosts' traffic too. For most troubleshooting you do not need promiscuous mode and can disable it under Capture → Options to reduce capture volume.
Capture filters vs display filters
Wireshark has two distinct filter systems. Capture filters use BPF (Berkeley Packet Filter) syntax and are applied in real time by the kernel before packets reach Wireshark — only matching packets are stored. They reduce file size and CPU load but cannot be changed after capture starts. Example: port 443 or host 192.168.1.1. Display filters are applied post-capture to the already-recorded data — you can add, remove, and change them without re-capturing. They use Wireshark's own richer syntax and can reference protocol fields that BPF cannot. For most interactive troubleshooting, capture everything (no capture filter) and narrow down with display filters.
Essential display filters
| Filter | What It Shows | Use When |
|---|---|---|
dns | All DNS queries and responses | Pages fail to load or names do not resolve |
tcp.port == 443 | All HTTPS traffic | Isolating HTTPS connections to inspect handshakes |
ip.addr == 192.168.1.1 | All traffic to or from one IP | Isolating traffic to a specific host |
tcp.flags.reset == 1 | TCP RST packets | Connections terminated unexpectedly |
tcp.analysis.retransmission | TCP retransmissions flagged by Wireshark | Confirming packet loss in real connections |
frame contains "password" | Packets whose payload contains the string | Auditing unencrypted credentials in plaintext protocols |
tls | TLS handshake and record traffic | HTTPS connection errors or certificate failures |
dhcp | IP address assignment traffic | DHCP failures or address conflicts |
Following streams
Individual packets show raw bytes. To read a full conversation as human-readable text, right-click any packet in the flow and choose Follow → TCP Stream (or UDP Stream, TLS Stream). Wireshark reassembles all packets from both directions into a single view, color-coded by direction. For unencrypted HTTP this shows the complete request and response. For TLS traffic the stream view shows encrypted bytes, but if you have loaded the session keys (via SSLKEYLOGFILE), Wireshark can decrypt and show plaintext. Following a stream also auto-populates a display filter isolating just that conversation.
Statistics features
Wireshark's Statistics menu provides aggregate views that are faster than reading individual packets. Statistics → Conversations lists all TCP/UDP/IP pairs sorted by bytes transferred — immediately shows which hosts are the top talkers and which flows carried the most data. Statistics → IO Graphs plots packets or bytes per second over time, making it easy to see bandwidth spikes, idle periods, or retransmission bursts correlated with time. Analyze → Expert Information summarizes Wireshark's automated anomaly detection: warnings for retransmissions, errors for RSTs and malformed packets, notes for window size issues and zero-window conditions — a fast first pass for spotting TCP problems.
Analyzing slow connections
When a connection is sluggish, look for these patterns in the packet list. TCP retransmissions (tcp.analysis.retransmission) appear as red rows — the same sequence number resent because the ACK was not received. Bursts of retransmissions correlate with packet loss. Zero window (tcp.analysis.zero_window) means the receiver's buffer is full and it is signaling the sender to stop — indicates the receiving application is not reading fast enough. Window size too small limits throughput even on a fast link — the TCP window caps how much in-flight data is allowed. Large time delta between a request packet and the server's response (visible in the Time column) indicates server-side processing delay rather than network transit time.
Saving filtered subsets
After applying a display filter, use File → Export Specified Packets to save only the matching packets to a new .pcapng file. This is useful for sharing a focused subset of a large capture with a colleague without exposing unrelated traffic. You can also mark specific packets (Edit → Mark/Unmark Packet) and export only marked packets.
Running without root on Linux
By default, capturing requires root privileges on Linux. Rather than running Wireshark as root (a security risk), grant the capture binary the needed capabilities: sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap. Dumpcap is the capture engine Wireshark uses; granting it capabilities lets normal users in the wireshark group capture without sudo. Add your user to the group with sudo usermod -aG wireshark $USER and log out and back in.
Command-line alternative: tshark
tshark is Wireshark's command-line counterpart — useful for capturing on remote servers or in scripts. Capture to a file: tshark -i eth0 -w capture.pcap. Read and filter an existing capture: tshark -r capture.pcap -Y "http". Decode and print a specific field from every packet: tshark -r capture.pcap -T fields -e dns.qry.name. tshark supports all Wireshark display filters via the -Y flag and all capture filters via -f.
What Common Problems Look Like
| Problem | Filter | Signature |
|---|---|---|
| DNS not resolving | dns | Queries sent; no response or NXDOMAIN reply |
| Packet loss | tcp.analysis.retransmission | Red rows; same sequence number resent |
| MTU / fragmentation | ip | ICMP "fragmentation needed" messages |
| TLS failure | tls | Client Hello, Server Hello, then TLS Alert or RST |
| Connection reset | tcp.flags.reset == 1 | RST packets immediately terminating connections |
Privacy Warning
Packet captures include hostnames (from TLS SNI), local IP addresses, cookies, session tokens, and unencrypted content from any non-HTTPS traffic. Before sharing a capture file with another person, review what is inside it. Strip sensitive data using Wireshark's Edit → Remove Packet Bytes, or anonymize IPs with editcap --anonymize-fields. Do not capture on networks you do not own or have explicit permission to monitor.
Frequently Asked Questions
Can Wireshark show passwords?
Sometimes, if traffic is unencrypted. It can also expose tokens and metadata, so treat captures as sensitive.
Do I need promiscuous mode?
Not for most troubleshooting on your own device. Capturing your device's traffic is usually enough.
What should I filter first?
Start with dns, tcp.analysis.retransmission, or the IP address of the server involved.
How do I capture on a remote machine?
Use tcpdump -i eth0 -w capture.pcap on the remote host, copy the file locally, and open it in Wireshark. Add filters like host 1.2.3.4 or port 443 to keep the file manageable.