Ultimate Wireshark Commands Cheat Sheet: Network Analysis and Packet Capture Reference

Wireshark is one of those tools I use constantly, but for years I only ever remembered about 20% of the filters and commands I actually needed in the moment. This cheat sheet is the reference I built for myself over time — the capture filters, display filters, command-line options, and troubleshooting workflows I reach for again and again. If you work in networking, security, or systems administration, I think you’ll find this useful too.

Wireshark vs Tshark: Know What You’re Using

Tool	Interface	Best For
Wireshark	GUI	Deep analysis, visual inspection, following streams
Tshark	Command-line	Scripting, automation, headless servers, remote captures
Dumpcap	Command-line	Lightweight capture-only tool, used internally by Wireshark

Installing Wireshark

Platform	Command
Ubuntu/Debian	sudo apt install wireshark
Fedora/RHEL	sudo dnf install wireshark
macOS (Homebrew)	brew install --cask wireshark
Windows	Download installer from official site

After installing on Linux, add your user to the wireshark group so you can capture without root:

sudo usermod -aG wireshark $USER

Then log out and back in for the group change to apply.

Capture Filters vs Display Filters (The Big Distinction)

This trips up a lot of beginners, so I want to be clear about it upfront:

Filter Type	When It Applies	Syntax Style	Purpose
Capture Filter	Before packets are captured	BPF (Berkeley Packet Filter) syntax	Reduces what gets recorded, saves disk/memory
Display Filter	After packets are captured	Wireshark’s own filter syntax	Narrows down what you view, doesn’t delete data

You can’t use display filter syntax in the capture filter box, and vice versa — they’re genuinely different languages.

Capture Filters Reference (BPF Syntax)

Filter	Purpose
host 192.168.1.10	Capture traffic to/from a specific host
net 192.168.1.0/24	Capture traffic within a subnet
port 443	Capture traffic on a specific port
portrange 1000-2000	Capture traffic within a port range
tcp	Capture only TCP traffic
udp	Capture only UDP traffic
icmp	Capture only ICMP traffic
src host 10.0.0.1	Capture traffic from a specific source
dst host 10.0.0.1	Capture traffic to a specific destination
not port 22	Exclude SSH traffic
host 10.0.0.1 and port 80	Combine conditions
broadcast	Capture broadcast traffic only
ether host aa:bb:cc:dd:ee:ff	Capture traffic for a specific MAC address

Display Filters Reference (Wireshark Syntax)

Basic Filters

Filter	Purpose
ip.addr == 192.168.1.10	Show traffic to/from an IP
ip.src == 192.168.1.10	Show traffic sourced from an IP
ip.dst == 192.168.1.10	Show traffic destined to an IP
tcp.port == 443	Show traffic on a TCP port
udp.port == 53	Show traffic on a UDP port
tcp.flags.syn == 1	Show SYN packets (connection attempts)
tcp.flags.reset == 1	Show RST packets (connection resets)
http	Show only HTTP traffic
dns	Show only DNS traffic
tls or ssl	Show TLS/SSL traffic
arp	Show ARP traffic
icmp	Show ICMP traffic

Combining Filters

Filter	Purpose
ip.addr == 10.0.0.1 && tcp.port == 443	Both conditions must match (AND)
tcp.port == 80 || tcp.port == 443	Either condition matches (OR)
!(tcp.port == 22)	Exclude a condition (NOT)
ip.addr == 10.0.0.1 and not icmp	Combine AND with NOT

Protocol-Specific Filters

Filter	Purpose
http.request.method == "POST"	Show only HTTP POST requests
http.response.code == 404	Show HTTP 404 responses
dns.qry.name == "example.com"	Show DNS queries for a specific domain
dns.flags.rcode != 0	Show DNS responses with errors
tls.handshake.type == 1	Show TLS Client Hello packets
tcp.analysis.retransmission	Show TCP retransmissions
tcp.analysis.duplicate_ack	Show duplicate ACKs
tcp.analysis.zero_window	Show zero window conditions (receiver buffer full)
ftp	Show FTP traffic
smtp	Show SMTP (email) traffic
icmp.type == 8	Show ICMP echo requests (ping)
icmp.type == 0	Show ICMP echo replies

Filtering by Frame/Time

Filter	Purpose
frame.len > 1000	Show packets larger than 1000 bytes
frame.time >= "2026-01-01 00:00:00"	Show packets after a specific time
frame.number == 500	Jump to a specific packet number
frame contains "password"	Search raw frame content for a string

Command-Line Capture with Tshark

Tshark is invaluable when you’re on a headless server or want to script captures.

# Basic capture to a file
tshark -i eth0 -w capture.pcap

# Capture with a capture filter (BPF syntax)
tshark -i eth0 -f "port 443" -w https_traffic.pcap

# Read and apply a display filter to an existing capture
tshark -r capture.pcap -Y "http.request"

# Limit capture to a specific number of packets
tshark -i eth0 -c 100 -w sample.pcap

# Capture for a set duration (in seconds)
tshark -i eth0 -a duration:60 -w timed_capture.pcap

# Output specific fields only, useful for scripting
tshark -r capture.pcap -T fields -e ip.src -e ip.dst -e tcp.port

# List available interfaces
tshark -D

Expected output for tshark -D:

1. eth0
2. wlan0
3. lo (Loopback)
4. any

Command-Line Capture with Dumpcap

# Capture packets on an interface with a size limit and ring buffer
dumpcap -i eth0 -b filesize:10240 -b files:5 -w rotating_capture.pcap

This is useful for long-running captures where you don’t want a single file to grow unbounded.

Following Streams

One of the most useful features for actually reading a conversation between two hosts:

Action	How To Do It (GUI)	Tshark Equivalent
Follow TCP Stream	Right-click packet > Follow > TCP Stream	tshark -r capture.pcap -q -z follow,tcp,ascii,0
Follow UDP Stream	Right-click packet > Follow > UDP Stream	tshark -r capture.pcap -q -z follow,udp,ascii,0
Follow HTTP Stream	Right-click packet > Follow > HTTP Stream	tshark -r capture.pcap -q -z follow,http,ascii,0

Statistics Menu Shortcuts

Feature	GUI Path	Purpose
Protocol Hierarchy	Statistics > Protocol Hierarchy	See a breakdown of protocols by volume
Conversations	Statistics > Conversations	See traffic grouped by endpoint pairs
Endpoints	Statistics > Endpoints	See traffic grouped by individual hosts
I/O Graph	Statistics > I/O Graph	Visualize traffic volume over time
Expert Info	Analyze > Expert Information	Surface warnings, errors, and notable events

Tshark equivalents:

# Protocol hierarchy statistics
tshark -r capture.pcap -q -z io,phs

# Conversation statistics
tshark -r capture.pcap -q -z conv,tcp

# Expert info summary
tshark -r capture.pcap -q -z expert

Coloring Rules (Reading Packets Faster)

Wireshark’s default coloring helps you scan a capture visually without reading every line:

Color	Meaning (Default Rules)
Black background, red text	Checksum errors
Light purple	TCP traffic
Light blue	UDP traffic
Black	TCP packets with problems (retransmissions, resets)
Green	HTTP traffic
Yellow	Routing protocols and warnings

You can customize these under View > Coloring Rules, and I’d recommend adding a rule to highlight retransmissions in a color you’ll spot instantly, since they’re often the first sign of network trouble.

Common Keyboard Shortcuts

Shortcut	Action
Ctrl+E	Start/stop capture
Ctrl+F	Find packet
Ctrl+G	Go to specific packet number
Ctrl+R	Reload capture file
Ctrl+Shift+T	Time display format toggle
Ctrl+M	Mark/unmark a packet
Ctrl+Alt+Shift+T	Follow TCP stream
Tab	Jump to display filter bar

Security and Threat-Hunting Filters

These are the ones I lean on most during incident response or general security review:

Filter	Purpose
tcp.flags == 0x002	Isolate SYN packets, useful for spotting port scans
tcp.flags == 0x029	Detect unusual FIN+PSH+URG combinations (potential scan technique)
dns.qry.name matches "\.xyz$"	Spot DNS queries to suspicious TLDs
http.request.uri contains "cmd="	Look for possible command injection attempts
frame contains "eval("	Search raw payload for suspicious script content
ip.ttl < 10	Spot unusually low TTL values, sometimes indicating spoofing or misconfigured tunneling
arp.duplicate-address-detected	Detect potential ARP spoofing / MITM attempts
tcp.analysis.retransmission and ip.addr == 10.0.0.5	Investigate connection quality issues from a specific host

Configuration Profiles and Customization

Wireshark’s configuration profiles let you save entirely separate setups (coloring rules, column layouts, filter buttons) for different jobs. I keep a dedicated profile for security investigations and a different one for general performance troubleshooting.

Task	GUI Path
Create a new profile	Edit > Configuration Profiles > “+”
Switch profiles	Right-click the profile name in the status bar
Customize columns	Edit > Preferences > Appearance > Columns
Add a custom filter button	Right-click the filter bar > “Apply as Filter” > save as button
Sanitize/anonymize a capture	Tools like tracewrangler (Windows) or bittwiste (cross-platform) work alongside Wireshark for this

Custom columns I add almost every time: TCP stream index, TCP window size, and delta time from previous displayed packet. They make scanning a busy capture much faster once they’re visible without opening every packet.

Exporting and Extracting Data

Task	How To Do It
Export specific packets	File > Export Specified Packets, choose displayed or marked packets
Export objects (files transferred over HTTP/SMB/etc.)	File > Export Objects > choose protocol
Export packet dissection as text/CSV	File > Export Packet Dissections
Extract fields via command line	tshark -r capture.pcap -T fields -e frame.number -e ip.src -E header=y -E separator=,
Convert pcap to pcapng or vice versa	editcap -F pcapng input.pcap output.pcapng
Merge multiple capture files	mergecap -w merged.pcap file1.pcap file2.pcap
Split a large capture into chunks	editcap -c 10000 large.pcap split.pcap

Exporting HTTP objects is genuinely one of my favorite features — if a capture includes a file download over plain HTTP, Wireshark can reconstruct and save that file directly from the packet data, which is incredibly useful for malware analysis or verifying what was actually transferred.

Building a Repeatable Capture Workflow

For anything beyond a quick ad hoc look, I try to follow a consistent process so captures stay usable later and don’t turn into an unlabeled pile of pcap files:

1. Name captures with context: hostname_issue-description_YYYYMMDD.pcap beats capture1.pcap every time.
2. Capture with a reasonable filter from the start if you already know the affected host or port, rather than capturing everything and filtering later.
3. Set a snap length if you only need headers, not full payload, to keep file sizes manageable: tshark -i eth0 -s 128 -w headers_only.pcap.
4. Rotate large captures automatically using dumpcap‘s ring buffer options rather than letting one file grow unbounded.
5. Document your filters alongside the capture — a short text file noting what you were investigating and which display filters you used saves everyone time if someone else picks up the analysis later.
6. Archive resolved investigations rather than deleting them; packet captures from a past incident are often useful reference material for the next similar one.

Troubleshooting Workflow

When I sit down with a packet capture to troubleshoot a real problem, this is roughly the order I work in:

1. Check Protocol Hierarchy first. This immediately tells me what kind of traffic dominates the capture and whether anything unexpected shows up.
2. Filter down to the affected host or conversation. Use ip.addr == to narrow the noise.
3. Look for retransmissions and resets. tcp.analysis.retransmission and tcp.flags.reset == 1 often point straight to the problem.
4. Check for DNS failures. dns.flags.rcode != 0 surfaces failed lookups quickly.
5. Follow the TCP stream for the specific connection in question to read the actual application-layer conversation.
6. Check Expert Info for anything Wireshark itself flagged as unusual.
7. Correlate timestamps with the reported issue window using the time filter to avoid wading through irrelevant traffic.

Common Symptom Table

Symptom	Filter to Investigate	Likely Cause
Slow application performance	tcp.analysis.zero_window	Receiver buffer exhausted
Intermittent connection drops	tcp.flags.reset == 1	Application or firewall resetting connections
DNS resolution failures	dns.flags.rcode != 0	Misconfigured DNS server or blocked queries
Packet loss suspicion	tcp.analysis.retransmission	Network congestion or faulty hardware
Suspected spoofing/MITM	arp.duplicate-address-detected	ARP cache poisoning
TLS handshake failures	tls.alert_message	Certificate mismatch or unsupported cipher suite

Best Practices

• Capture on the interface closest to the problem, not just whichever is convenient — a capture from the wrong segment can hide the real issue.
• Use capture filters to reduce noise when you already know what you’re looking for; save display filters for exploratory analysis.
• Save captures with descriptive filenames and timestamps, especially in incident response contexts where chain of custody matters.
• Avoid capturing more than you need in production environments — full packet capture on a busy link can fill disk space fast.
• When sharing captures with colleagues or vendors, sanitize sensitive payload data first (Wireshark has built-in tools for this under Edit > Configuration Profiles).
• Learn tshark even if you prefer the GUI; it’s the only option on headless systems and it scripts beautifully into automated monitoring.

Real-World Use Cases

• Diagnosing slow file transfers by checking for zero window conditions and retransmissions between client and server.
• Investigating a suspected man-in-the-middle attack by filtering for duplicate ARP replies on a LAN segment.
• Auditing DNS traffic to catch exfiltration attempts disguised as DNS queries to unusual domains.
• Validating a TLS/SSL certificate rollout by confirming the correct certificate chain appears in the handshake.
• Capturing evidence during a security incident using tshark on a server without a GUI, then analyzing the resulting pcap on a workstation.
• Baselining normal traffic patterns with Statistics > Conversations before an infrastructure change, so you have something to compare against afterward.

Common Mistakes to Avoid

• Mixing up capture filter syntax and display filter syntax — they are not interchangeable, and using one in the other’s field will either fail or silently do nothing useful.
• Capturing on the wrong interface, especially in virtualized or multi-homed environments.
• Leaving a full packet capture running unattended on a high-traffic link and running out of disk space.
• Forgetting that tcp.port filters both source and destination — if you need directionality, use tcp.srcport or tcp.dstport specifically.
• Not checking Expert Info before manually hunting through thousands of packets — it often surfaces the issue directly.
• Assuming a single retransmission means a serious problem; occasional retransmissions are normal on any network. Look for patterns, not one-offs.

FAQs

What’s the difference between a capture filter and a display filter? Capture filters use BPF syntax and determine what gets recorded during the capture itself. Display filters use Wireshark’s own syntax and only change what’s shown from already-captured data — nothing is deleted.

Can I run Wireshark without root/administrator privileges? On Linux, yes, if your user is added to the wireshark group so dumpcap can access raw sockets without full root. On Windows, the Npcap driver handles this after installation, and you may still need admin rights for the initial setup.

How do I capture traffic on a remote server without a GUI? Use tshark or dumpcap on the remote machine to write a .pcap file, then transfer it to a workstation with the Wireshark GUI for deeper analysis.

Why can’t I see HTTPS traffic content even though I captured it? TLS encrypts the payload, so you’ll see the handshake and metadata but not the application data unless you have the session keys (via SSLKEYLOGFILE) or a private key for decryption configured in Wireshark.

What does “tcp.analysis.retransmission” actually indicate? It flags packets Wireshark believes were retransmitted, usually because the original packet was lost or the ACK wasn’t received in time. Occasional retransmissions are normal; frequent ones suggest congestion or a flaky link.

Interview Questions on Wireshark

1. What’s the difference between a capture filter and a display filter, and can you give an example of each?
2. How would you identify TCP retransmissions in a packet capture, and what do they typically indicate?
3. Walk through how you’d investigate a suspected ARP spoofing attack using Wireshark.
4. What’s the purpose of the “Follow TCP Stream” feature, and when would you use it?
5. How do you capture traffic on a headless Linux server without a GUI?
6. Explain how you’d decrypt TLS traffic in Wireshark, assuming you have access to the session keys.
7. What’s the difference between tcp.port and tcp.srcport/tcp.dstport?
8. How would you use Wireshark’s Statistics menu to baseline normal network behavior?
9. What are some signs in a packet capture that indicate a DNS-based exfiltration attempt?
10. Describe a real troubleshooting scenario where packet capture analysis solved a problem other tools couldn’t.

Printable Quick-Reference Summary

Category	Key Command/Filter
Capture on interface	tshark -i eth0 -w capture.pcap
Capture with filter	tshark -i eth0 -f "port 443"
Read existing capture	tshark -r capture.pcap
Display filter (IP)	ip.addr == 192.168.1.10
Display filter (port)	tcp.port == 443
Show retransmissions	tcp.analysis.retransmission
Show SYN packets	tcp.flags.syn == 1
Follow TCP stream (CLI)	tshark -r capture.pcap -q -z follow,tcp,ascii,0
Protocol hierarchy (CLI)	tshark -r capture.pcap -q -z io,phs
List interfaces	tshark -D
DNS query filter	dns.qry.name == "example.com"
ARP spoof detection	arp.duplicate-address-detected

Official Documentation and Further Reading

• Wireshark User’s Guide
• Wireshark Display Filter Reference
• Tshark Manual Page
• Wireshark Wiki – Capture Filters
• Wireshark Wiki – Security Analysis Tips

I go back to this cheat sheet constantly, whether I’m doing routine network health checks or digging into an actual incident. Bookmark it, print the summary table if that’s your style, and hopefully it saves you the same rabbit holes it’s saved me.