Packet Capture — Network Troubleshooting | OneNoughtOne

0/107

Computer NetworksTroubleshooting

Network Troubleshooting

LevelIntermediate

Duration75 mins

TopicTroubleshooting

4 / 5

Packet Capture

When Packets Don't Lie

Ping tells you if packets reach a destination. Traceroute tells you where they go. But when you need to know exactly what is being transmitted—every byte, every header, every protocol exchange—you turn to packet capture . Packet capture (sometimes called 'sniffing' or 'packet analysis') records the actual data traversing a network interface. Where other tools provide summaries and statistics, packet capture provides ground truth . When an application claims it sent the right data, when a firewall claims it's allowing traffic, when a server claims it never received a request—packet capture proves or disproves those claims definitively. The definitive diagnostic: Packet capture is the ultimate troubleshooting escalation. When simpler tools can't explain a problem, packet analysis reveals exactly what's happening at the wire level. It's how security analysts detect intrusions, how developers debug protocols, and how engineers prove (or disprove) that 'the network is the problem.'

What You Will Learn

This page covers packet capture fundamentals using Wireshark and tcpdump—when and how to capture, filter syntax (capture vs display), reading packet headers, following streams, and common analysis patterns for TCP, HTTP, DNS, and TLS. You'll develop the ability to diagnose problems that other tools can't touch.

Packet Capture Fundamentals

Before diving into tools, understand how packet capture works and its inherent limitations. How Capture Works: Normally, a network interface card (NIC) only accepts packets destined for its MAC address (or broadcast/multicast addresses). Packet capture puts the NIC into promiscuous mode, where it accepts all packets seen on the network segment. On switched networks (most modern networks), this only captures traffic to/from the capturing host plus broadcast/multicast traffic—you won't see traffic between other hosts unless you take additional steps. Seeing Other Hosts' Traffic:

Methods to Capture Traffic Between Other Hosts
Method	How It Works	Use Case
Port Mirroring (SPAN)	Switch copies traffic from one port to another	Production network monitoring
Network TAP	Physical device that copies traffic passively	High-fidelity captures, security monitoring
Hub (legacy)	All traffic broadcast to all ports	Lab environments only
ARP Spoofing	Redirect traffic through your host	Penetration testing (with authorization only!)
Inline Capture	Capture device placed in traffic path	Firewall/IDS deployments
Agent on Host	Capture on the source or destination itself	Most common approach—capture where the traffic is

What Gets Captured: A packet capture includes: Frame header — Layer 2 (Ethernet): Source/destination MAC, EtherType IP header — Layer 3: Source/destination IP, TTL, protocol, flags Transport header — Layer 4: Source/destination ports, flags, sequence numbers (TCP) Payload — Layer 7: Application data (if unencrypted) Limitations and Considerations:

Packet Capture Considerations

•Encryption — TLS/HTTPS traffic shows only encrypted blobs without decryption keys. You see metadata (IPs, ports, timing) but not content.
•Capture drops — Under high load, the capture system may drop packets. Statistics tell you if this happened.
•Storage — Packet captures can be huge. 1 Gbps link = ~125 MB/second = 7.5 GB/minute. Plan capture duration carefully.
•Privacy and legal — Capturing traffic may require authorization. Capture data can contain sensitive information. Handle with care.
•Timestamps — Capture timestamps reflect when the capturing system saw the packet, not when it was sent. Clock synchronization matters.

Authorization Required

Never capture network traffic without explicit authorization. In many jurisdictions, unauthorized packet capture is illegal (wiretapping laws). In enterprise environments, follow your organization's policies. Even with authorization, handle capture data as sensitive.

tcpdump - Command-Line Capture

tcpdump is the standard command-line packet capture tool on Unix-like systems. It's lightweight, scriptable, and available on virtually every Linux/Unix system. For servers without a GUI, tcpdump is indispensable. Basic Capture Commands:

tcpdump Examples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# List available interfaces
tcpdump -D
 
# Capture on specific interface (requires root)
sudo tcpdump -i eth0
 
# Capture with verbose output
sudo tcpdump -i eth0 -v      # Verbose
sudo tcpdump -i eth0 -vv     # More verbose
sudo tcpdump -i eth0 -vvv    # Maximum verbosity
 
# Don't resolve hostnames or ports (faster, clearer)
sudo tcpdump -i eth0 -nn
 
# Limit capture to N packets
sudo tcpdump -i eth0 -c 100
 
# Save to file (for later Wireshark analysis)
sudo tcpdump -i eth0 -w capture.pcap
 
# Read from saved file
tcpdump -r capture.pcap
 
# Show absolute sequence numbers
sudo tcpdump -i eth0 -S

Reading tcpdump Output: 14:32:45.123456 IP 192.168.1.100.54321 > 93.184.216.34.80: Flags [S], seq 123456789, win 65535, options [mss 1460,nop,nop,sackOK], length 0

Field	Meaning
`14:32:45.123456`	Timestamp (HH:MM:SS.microseconds)
`IP`	IPv4 packet
`192.168.1.100.54321`	Source IP.port
`>`	Direction (to)
`93.184.216.34.80`	Destination IP.port
`Flags [S]`	TCP flags (S=SYN)
`seq 123456789`	TCP sequence number
`win 65535`	TCP window size
`options [...]`	TCP options (MSS, SACK, etc.)
`length 0`	Payload bytes (0 for SYN)

Common TCP Flags:

Flag	Letter	Meaning
SYN	S	Connection initiation
ACK	.	Acknowledgment
FIN	F	Connection termination
RST	R	Reset (abort connection)
PSH	P	Push (send immediately)
SYN-ACK	S.	SYN + ACK (handshake step 2)

Best Practice: Capture to File

For serious analysis, always capture to a pcap file (-w capture.pcap) then analyze with Wireshark. Real-time tcpdump output scrolls by too fast for complex analysis. Files can also be shared with colleagues or vendors for collaborative troubleshooting.

Wireshark - GUI Protocol Analyzer

Wireshark is the world's most popular network protocol analyzer. It provides a graphical interface for capturing and analyzing packets, with deep protocol decoding for hundreds of protocols. Wireshark Interface Components: Packet List Pane — List of captured packets with summary info Packet Details Pane — Protocol decode tree for selected packet Packet Bytes Pane — Raw hex/ASCII view of packet Display Filter Bar — Filter displayed packets (not capture) Toolbar — Start/stop capture, file operations, etc. Starting a Capture: Select interface from capture selector (Optional) Set capture filter Click Start or double-click interface Packets appear in real-time Click Stop when done Save with File > Save As

Capture Filters vs Display Filters: Wireshark has two types of filters with different syntaxes:

Aspect	Capture Filter	Display Filter
When applied	During capture	After capture
Syntax	BPF (same as tcpdump)	Wireshark-specific
Effect	Limits what's captured	Limits what's shown
Use case	Reduce capture size	Focus analysis
Changeable	No (set before capture)	Yes (interactive)

When to use each: Capture filter: When you know exactly what you need and want to minimize file size Display filter: When you're exploring or need to see different traffic types from the same capture

Wireshark Filter Syntax

# Host filters
host 192.168.1.100
src host 192.168.1.100
dst host 192.168.1.100
 
# Port filters
port 80
port 443 or port 80
src port 443
dst port 80
 
# Protocol filters
tcp
udp
icmp
 
# Network filters
net 192.168.1.0/24
net 10.0.0.0/8
 
# Combinations
host 192.168.1.100 and port 443
tcp port 80 and host 10.0.0.5
not port 22
port 80 and (host 10.0.0.1 or host 10.0.0.2)
 
# Packet size
greater 1000
less 64

Essential Wireshark Features

•Follow TCP Stream — Right-click packet > Follow > TCP Stream. Shows entire conversation reconstructed.
•Statistics > Conversations — Shows all connections with bytes/packets exchanged.
•Statistics > Protocol Hierarchy — What protocols are in the capture and their percentages.
•Statistics > I/O Graph — Visual representation of traffic over time.
•Analyze > Expert Information — Wireshark's analysis of problems (retransmissions, resets, etc.).
•File > Export Objects > HTTP — Extract files transferred over HTTP.
•Coloring Rules — Packets colored by type (Edit > Coloring Rules or predefined).

The Expert Information

Always check Analyze > Expert Information when troubleshooting. Wireshark automatically detects TCP retransmissions, zero window events, RST packets, sequence problems, and other anomalies. It categorizes them by severity (Chat, Note, Warning, Error).

Analyzing TCP Issues

TCP problems are among the most common reasons for packet analysis. Understanding what to look for accelerates diagnosis. The TCP Three-Way Handshake: Every TCP connection starts with this exchange: Client Server | | |---- SYN (seq=x) ------------------->| | | |<--- SYN-ACK (seq=y, ack=x+1) -------| | | |---- ACK (ack=y+1) ----------------->| | | Connection Established In Wireshark: 192.168.1.100:54321 -> 93.184.216.34:80 [SYN] seq=0 93.184.216.34:80 -> 192.168.1.100:54321 [SYN,ACK] seq=0 ack=1 192.168.1.100:54321 -> 93.184.216.34:80 [ACK] ack=1 Handshake Problems:

TCP Connection Problems
Pattern	Meaning	Cause
SYN sent, no response	Timeout	Host down, firewall drops, routing issue
SYN sent, RST received	Port closed	Service not listening, firewall rejects
SYN sent, ICMP unreachable	Host/network unreachable	Routing or firewall issue
SYN-ACK received, no ACK from client	Client-side issue	Client firewall, NAT problem
Multiple SYN retransmissions	Packet loss or filtering	Network congestion, firewall

Retransmission Analysis: TCP retransmits lost packets. In Wireshark, filter with tcp.analysis.retransmission . Types of retransmissions:

Type	What It Means	Wireshark Filter
Retransmission	Packet resent after timeout	`tcp.analysis.retransmission`
Fast Retransmission	Resent after duplicate ACKs	`tcp.analysis.fast_retransmission`
Spurious Retransmission	Unnecessary resend (original was received)	`tcp.analysis.spurious_retransmission`
Out-of-Order	Packet arrived out of sequence	`tcp.analysis.out_of_order`
Duplicate ACK	ACK for already-acknowledged data	`tcp.analysis.duplicate_ack`

What retransmissions tell you: Few retransmissions (< 1%) = Normal network operation Moderate retransmissions (1-5%) = Network congestion or quality issues High retransmissions (> 5%) = Significant packet loss, investigate path

Window Size Analysis: TCP window size controls flow control. Look for: Zero Window: Receiver is overwhelmed, tells sender to stop. Filter: tcp.analysis.zero_window Window Update: Receiver recovered, tells sender to resume. Filter: tcp.analysis.window_update Small Window: Limits throughput possible. Check in packet details. RST (Reset) Analysis: RST packets abruptly terminate connections. Filter: tcp.flags.rst == 1

RST Scenario	Likely Cause
RST after SYN	Port not listening
RST mid-connection	Application crashed, timeout, firewall kill
RST after FIN	Connection already closing
RST from unexpected IP	Firewall or middlebox interference

Connection Termination: Normal close = FIN-ACK exchange (graceful): Client --> FIN --> Server Client <-- ACK <-- Server Client <-- FIN <-- Server Client --> ACK --> Server Abrupt close = RST: One RST terminates immediately Check why (application crash? timeout? firewall?)

TCP Stream Reconstruction

Right-click any TCP packet > Follow > TCP Stream to see the entire conversation reconstructed as a continuous data stream. This is invaluable for understanding what data was actually exchanged, especially for text protocols like HTTP.

Analyzing DNS Traffic

DNS issues are extremely common and often cause 'the network is slow' complaints (DNS timeout adds seconds to every new connection). Packet capture reveals exactly what's happening with name resolution. Display Filter: dns DNS Query/Response Pattern: Query: 192.168.1.100 -> 8.8.8.8: Standard query A www.example.com Response: 8.8.8.8 -> 192.168.1.100: Standard query response A www.example.com A 93.184.216.34 What to Look For in DNS:

DNS Analysis Patterns
Pattern	Filter	Meaning
Many queries, no responses	`dns.qry.name`	DNS server unreachable or blocking
Response with no answer	`dns.count.answers == 0`	NXDOMAIN (name doesn't exist)
Single query, multiple responses	Compare transaction IDs	Possible DNS spoofing
High query time	Check timestamp delta	Slow DNS server
Query to unexpected server	Check destination IP	Misconfigured DNS or DNS hijacking
PTR queries flooding	`dns.qry.type == 12`	Something doing reverse lookups excessively

DNS Response Codes:

Code	Name	Meaning
0	NOERROR	Success
1	FORMERR	Format error
2	SERVFAIL	Server failed
3	NXDOMAIN	Name doesn't exist
5	REFUSED	Server refused query

Filter by response code: dns.flags.rcode == 3 (NXDOMAIN) Wireshark DNS Dissection: Expand the DNS protocol in packet details to see: Transaction ID (matches query to response) Flags: Query/Response, Recursion Desired/Available Questions: What was asked Answers: What was returned Authority: Authoritative nameservers Additional: Extra records (glue records, etc.) Example Analysis Workflow: Filter dns to see only DNS traffic Look for unanswered queries (query without matching response) Check response codes for errors Note response times (time between query and response packets) Verify responses contain expected IP addresses

DNS Filters

Wireshark Display Filters

# All DNS traffic
dns
 
# DNS queries only
dns.flags.response == 0
 
# DNS responses only
dns.flags.response == 1
 
# Specific domain
dns.qry.name == "www.example.com"
dns.qry.name contains "example"
 
# NXDOMAIN responses
dns.flags.rcode == 3
 
# A record queries
dns.qry.type == 1
 
# AAAA (IPv6) record queries
dns.qry.type == 28
 
# MX record queries
dns.qry.type == 15
 
# PTR (reverse) queries
dns.qry.type == 12
 
# DNS over specific port (non-standard)
dns and !udp.port == 53

DNS Timeouts Add Up

If you see DNS queries with no responses, note that most resolvers wait 1-5 seconds before retrying or failing. Multiple failed queries in a row can cause perceived delays of 15+ seconds before an application sees an error. This often manifests as 'the website is slow to load.'

Analyzing HTTP/HTTPS Traffic

Web traffic analysis is a core packet capture skill. While HTTPS encrypts the payload, you can still learn a lot from connection patterns. HTTP (Unencrypted) Analysis: Display filter: http HTTP Request Fields: GET /api/users HTTP/1.1 Host: api.example.com User-Agent: Mozilla/5.0... Accept: application/json Cookie: session=abc123 Useful HTTP Filters:

HTTP Analysis Filters

Display Filters

# All HTTP traffic
http
 
# HTTP requests only
http.request
 
# HTTP responses only
http.response
 
# Specific methods
http.request.method == "GET"
http.request.method == "POST"
http.request.method == "PUT"
 
# Response codes
http.response.code == 200
http.response.code == 404
http.response.code == 500
http.response.code >= 400    # All errors
http.response.code >= 500    # Server errors only
 
# URL filtering
http.request.uri contains "/api/"
http.host == "api.example.com"
http.host contains "example"
 
# Content type
http.content_type contains "json"
http.content_type contains "html"
 
# User agent
http.user_agent contains "Mozilla"
http.user_agent contains "curl"

Analyzing Request/Response Pairs: Filter to http.request or http.response Right-click a request > Follow > HTTP Stream See complete request and response together Common HTTP problems in captures:

Symptom	What You See	Likely Cause
Slow page load	Large response, multiple requests	Unoptimized page, many resources
Page timeout	Request, no response (or delayed)	Server overloaded or crashed
4xx errors	400/401/403/404 responses	Client error, auth issue, missing resource
5xx errors	500/502/503/504 responses	Server error, overload, timeout
Redirect loops	Multiple 301/302 in sequence	Misconfigured redirects

HTTPS/TLS Analysis: HTTPS encrypts the payload, but you can still see: IP addresses (source/destination) Port numbers (typically 443) TLS handshake (version negotiation, cipher selection) SNI (Server Name Indication) - the hostname in Client Hello Certificate information (in some cases) Connection patterns (timing, sizes) TLS Filters: tls # All TLS traffic tls.handshake # Handshake messages only tls.handshake.type == 1 # Client Hello tls.handshake.type == 2 # Server Hello tls.handshake.extensions_server_name # SNI hostname ssl.alert_message # TLS alerts (errors) TLS Troubleshooting:

Problem	What You See	Cause
Version mismatch	Client Hello with old version, server RST	Server doesn't support client's TLS version
Cipher mismatch	Handshake failure alert	No common cipher suite
Certificate error	Certificate alert	Expired, wrong hostname, untrusted CA
Slow handshake	Large time gaps between handshake packets	Server overload or network latency

Decrypting HTTPS

You can decrypt HTTPS in Wireshark if you have the TLS session keys. Browsers like Chrome/Firefox can export these keys (set SSLKEYLOGFILE environment variable). Then configure Wireshark: Edit > Preferences > Protocols > TLS > (Pre-)Master-Secret log filename. This is essential for debugging HTTPS issues in development environments.

Capture Best Practices

Effective packet capture requires planning. The difference between a useful capture and a useless one is often preparation. Before Capturing:

Pre-Capture Checklist

•Define the problem — What specific behavior are you trying to capture?
•Identify endpoints — What IPs/ports should you filter on?
•Choose capture point — Client, server, or network device?
•Estimate duration — Short burst or sustained capture?
•Plan storage — Do you have space for the expected capture size?
•Coordinate reproduction — Can you trigger the problem on demand?
•Document environment — Record IP addresses, hostnames, topology

Capture Point Selection:

Capture At	Pros	Cons
Client	See exactly what client sends/receives	May lack visibility to network issues
Server	See what server receives/sends	May miss client-side network issues
Switch (SPAN port)	See transit traffic	Adds complexity, may drop packets under load
Firewall/Router	See traffic at network boundary	Limited to what passes through that point
Both ends	Complete picture	Requires coordination, more data to analyze

Filter Strategy: Capture filters: Use when you know exactly what traffic you need and want to limit file size Display filters: Use when exploring or when you need to see multiple traffic types from same capture Start broad, narrow down: Better to capture too much and filter later than miss the critical packet Dealing with Large Captures:

Large Capture Techniques
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Rotate files after size limit (100MB each, keep 10)
sudo tcpdump -i eth0 -w capture.pcap -C 100 -W 10
 
# Ring buffer: overwrites oldest file when limit reached
sudo tcpdump -i eth0 -w capture.pcap -C 50 -W 5 -Z root
 
# Capture for specific duration (60 seconds)
timeout 60 sudo tcpdump -i eth0 -w capture.pcap
 
# Capture with timestamp in filename
sudo tcpdump -i eth0 -w capture_$(date +%Y%m%d_%H%M%S).pcap
 
# Split capture by packet count
sudo tcpdump -i eth0 -c 10000 -w capture.pcap

Common Mistakes

•Capturing without clear goal
•Forgetting to include timestamps
•Running out of disk space mid-capture
•Capturing on wrong interface
•Not documenting IP-to-hostname mappings
•Truncating packets (old -s 68 default)
•Capturing too long (excessive data)

Best Practices

•Define problem before capturing
•Use ring buffer for long captures
•Check interface selection
•Document environment in notes file
•Include full packets (-s 0)
•Capture at both endpoints when possible
•Save original, work on copy

Sharing Captures

When sharing captures for collaborative troubleshooting: (1) Anonymize if needed (Tools > Statistics > Edit Resolved Name), (2) Filter to relevant traffic only, (3) Include a notes file documenting IPs, issue description, and what to look for. A well-documented capture gets faster help.

Computer NetworksTroubleshooting

Network Troubleshooting

LevelIntermediate

Duration75 mins

TopicTroubleshooting

4 / 5

Packet Capture

When Packets Don't Lie

Ping tells you if packets reach a destination. Traceroute tells you where they go. But when you need to know exactly what is being transmitted—every byte, every header, every protocol exchange—you turn to packet capture . Packet capture (sometimes called 'sniffing' or 'packet analysis') records the actual data traversing a network interface. Where other tools provide summaries and statistics, packet capture provides ground truth . When an application claims it sent the right data, when a firewall claims it's allowing traffic, when a server claims it never received a request—packet capture proves or disproves those claims definitively. The definitive diagnostic: Packet capture is the ultimate troubleshooting escalation. When simpler tools can't explain a problem, packet analysis reveals exactly what's happening at the wire level. It's how security analysts detect intrusions, how developers debug protocols, and how engineers prove (or disprove) that 'the network is the problem.'

What You Will Learn

This page covers packet capture fundamentals using Wireshark and tcpdump—when and how to capture, filter syntax (capture vs display), reading packet headers, following streams, and common analysis patterns for TCP, HTTP, DNS, and TLS. You'll develop the ability to diagnose problems that other tools can't touch.

Packet Capture Fundamentals

Before diving into tools, understand how packet capture works and its inherent limitations. How Capture Works: Normally, a network interface card (NIC) only accepts packets destined for its MAC address (or broadcast/multicast addresses). Packet capture puts the NIC into promiscuous mode, where it accepts all packets seen on the network segment. On switched networks (most modern networks), this only captures traffic to/from the capturing host plus broadcast/multicast traffic—you won't see traffic between other hosts unless you take additional steps. Seeing Other Hosts' Traffic:

Methods to Capture Traffic Between Other Hosts
Method	How It Works	Use Case
Port Mirroring (SPAN)	Switch copies traffic from one port to another	Production network monitoring
Network TAP	Physical device that copies traffic passively	High-fidelity captures, security monitoring
Hub (legacy)	All traffic broadcast to all ports	Lab environments only
ARP Spoofing	Redirect traffic through your host	Penetration testing (with authorization only!)
Inline Capture	Capture device placed in traffic path	Firewall/IDS deployments
Agent on Host	Capture on the source or destination itself	Most common approach—capture where the traffic is

What Gets Captured: A packet capture includes: Frame header — Layer 2 (Ethernet): Source/destination MAC, EtherType IP header — Layer 3: Source/destination IP, TTL, protocol, flags Transport header — Layer 4: Source/destination ports, flags, sequence numbers (TCP) Payload — Layer 7: Application data (if unencrypted) Limitations and Considerations:

Packet Capture Considerations

•Encryption — TLS/HTTPS traffic shows only encrypted blobs without decryption keys. You see metadata (IPs, ports, timing) but not content.
•Capture drops — Under high load, the capture system may drop packets. Statistics tell you if this happened.
•Storage — Packet captures can be huge. 1 Gbps link = ~125 MB/second = 7.5 GB/minute. Plan capture duration carefully.
•Privacy and legal — Capturing traffic may require authorization. Capture data can contain sensitive information. Handle with care.
•Timestamps — Capture timestamps reflect when the capturing system saw the packet, not when it was sent. Clock synchronization matters.

Authorization Required

Never capture network traffic without explicit authorization. In many jurisdictions, unauthorized packet capture is illegal (wiretapping laws). In enterprise environments, follow your organization's policies. Even with authorization, handle capture data as sensitive.

tcpdump - Command-Line Capture

tcpdump is the standard command-line packet capture tool on Unix-like systems. It's lightweight, scriptable, and available on virtually every Linux/Unix system. For servers without a GUI, tcpdump is indispensable. Basic Capture Commands:

tcpdump Examples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# List available interfaces
tcpdump -D
 
# Capture on specific interface (requires root)
sudo tcpdump -i eth0
 
# Capture with verbose output
sudo tcpdump -i eth0 -v      # Verbose
sudo tcpdump -i eth0 -vv     # More verbose
sudo tcpdump -i eth0 -vvv    # Maximum verbosity
 
# Don't resolve hostnames or ports (faster, clearer)
sudo tcpdump -i eth0 -nn
 
# Limit capture to N packets
sudo tcpdump -i eth0 -c 100
 
# Save to file (for later Wireshark analysis)
sudo tcpdump -i eth0 -w capture.pcap
 
# Read from saved file
tcpdump -r capture.pcap
 
# Show absolute sequence numbers
sudo tcpdump -i eth0 -S

Reading tcpdump Output: 14:32:45.123456 IP 192.168.1.100.54321 > 93.184.216.34.80: Flags [S], seq 123456789, win 65535, options [mss 1460,nop,nop,sackOK], length 0

Field	Meaning
`14:32:45.123456`	Timestamp (HH:MM:SS.microseconds)
`IP`	IPv4 packet
`192.168.1.100.54321`	Source IP.port
`>`	Direction (to)
`93.184.216.34.80`	Destination IP.port
`Flags [S]`	TCP flags (S=SYN)
`seq 123456789`	TCP sequence number
`win 65535`	TCP window size
`options [...]`	TCP options (MSS, SACK, etc.)
`length 0`	Payload bytes (0 for SYN)

Common TCP Flags:

Flag	Letter	Meaning
SYN	S	Connection initiation
ACK	.	Acknowledgment
FIN	F	Connection termination
RST	R	Reset (abort connection)
PSH	P	Push (send immediately)
SYN-ACK	S.	SYN + ACK (handshake step 2)

Best Practice: Capture to File

For serious analysis, always capture to a pcap file (-w capture.pcap) then analyze with Wireshark. Real-time tcpdump output scrolls by too fast for complex analysis. Files can also be shared with colleagues or vendors for collaborative troubleshooting.

Wireshark - GUI Protocol Analyzer

Wireshark is the world's most popular network protocol analyzer. It provides a graphical interface for capturing and analyzing packets, with deep protocol decoding for hundreds of protocols. Wireshark Interface Components: Packet List Pane — List of captured packets with summary info Packet Details Pane — Protocol decode tree for selected packet Packet Bytes Pane — Raw hex/ASCII view of packet Display Filter Bar — Filter displayed packets (not capture) Toolbar — Start/stop capture, file operations, etc. Starting a Capture: Select interface from capture selector (Optional) Set capture filter Click Start or double-click interface Packets appear in real-time Click Stop when done Save with File > Save As

Capture Filters vs Display Filters: Wireshark has two types of filters with different syntaxes:

Aspect	Capture Filter	Display Filter
When applied	During capture	After capture
Syntax	BPF (same as tcpdump)	Wireshark-specific
Effect	Limits what's captured	Limits what's shown
Use case	Reduce capture size	Focus analysis
Changeable	No (set before capture)	Yes (interactive)

When to use each: Capture filter: When you know exactly what you need and want to minimize file size Display filter: When you're exploring or need to see different traffic types from the same capture

Wireshark Filter Syntax

# Host filters
host 192.168.1.100
src host 192.168.1.100
dst host 192.168.1.100
 
# Port filters
port 80
port 443 or port 80
src port 443
dst port 80
 
# Protocol filters
tcp
udp
icmp
 
# Network filters
net 192.168.1.0/24
net 10.0.0.0/8
 
# Combinations
host 192.168.1.100 and port 443
tcp port 80 and host 10.0.0.5
not port 22
port 80 and (host 10.0.0.1 or host 10.0.0.2)
 
# Packet size
greater 1000
less 64

Essential Wireshark Features

•Follow TCP Stream — Right-click packet > Follow > TCP Stream. Shows entire conversation reconstructed.
•Statistics > Conversations — Shows all connections with bytes/packets exchanged.
•Statistics > Protocol Hierarchy — What protocols are in the capture and their percentages.
•Statistics > I/O Graph — Visual representation of traffic over time.
•Analyze > Expert Information — Wireshark's analysis of problems (retransmissions, resets, etc.).
•File > Export Objects > HTTP — Extract files transferred over HTTP.
•Coloring Rules — Packets colored by type (Edit > Coloring Rules or predefined).

The Expert Information

Always check Analyze > Expert Information when troubleshooting. Wireshark automatically detects TCP retransmissions, zero window events, RST packets, sequence problems, and other anomalies. It categorizes them by severity (Chat, Note, Warning, Error).

Analyzing TCP Issues

TCP problems are among the most common reasons for packet analysis. Understanding what to look for accelerates diagnosis. The TCP Three-Way Handshake: Every TCP connection starts with this exchange: Client Server | | |---- SYN (seq=x) ------------------->| | | |<--- SYN-ACK (seq=y, ack=x+1) -------| | | |---- ACK (ack=y+1) ----------------->| | | Connection Established In Wireshark: 192.168.1.100:54321 -> 93.184.216.34:80 [SYN] seq=0 93.184.216.34:80 -> 192.168.1.100:54321 [SYN,ACK] seq=0 ack=1 192.168.1.100:54321 -> 93.184.216.34:80 [ACK] ack=1 Handshake Problems:

TCP Connection Problems
Pattern	Meaning	Cause
SYN sent, no response	Timeout	Host down, firewall drops, routing issue
SYN sent, RST received	Port closed	Service not listening, firewall rejects
SYN sent, ICMP unreachable	Host/network unreachable	Routing or firewall issue
SYN-ACK received, no ACK from client	Client-side issue	Client firewall, NAT problem
Multiple SYN retransmissions	Packet loss or filtering	Network congestion, firewall

Retransmission Analysis: TCP retransmits lost packets. In Wireshark, filter with tcp.analysis.retransmission . Types of retransmissions:

Type	What It Means	Wireshark Filter
Retransmission	Packet resent after timeout	`tcp.analysis.retransmission`
Fast Retransmission	Resent after duplicate ACKs	`tcp.analysis.fast_retransmission`
Spurious Retransmission	Unnecessary resend (original was received)	`tcp.analysis.spurious_retransmission`
Out-of-Order	Packet arrived out of sequence	`tcp.analysis.out_of_order`
Duplicate ACK	ACK for already-acknowledged data	`tcp.analysis.duplicate_ack`

What retransmissions tell you: Few retransmissions (< 1%) = Normal network operation Moderate retransmissions (1-5%) = Network congestion or quality issues High retransmissions (> 5%) = Significant packet loss, investigate path

Window Size Analysis: TCP window size controls flow control. Look for: Zero Window: Receiver is overwhelmed, tells sender to stop. Filter: tcp.analysis.zero_window Window Update: Receiver recovered, tells sender to resume. Filter: tcp.analysis.window_update Small Window: Limits throughput possible. Check in packet details. RST (Reset) Analysis: RST packets abruptly terminate connections. Filter: tcp.flags.rst == 1

RST Scenario	Likely Cause
RST after SYN	Port not listening
RST mid-connection	Application crashed, timeout, firewall kill
RST after FIN	Connection already closing
RST from unexpected IP	Firewall or middlebox interference

Connection Termination: Normal close = FIN-ACK exchange (graceful): Client --> FIN --> Server Client <-- ACK <-- Server Client <-- FIN <-- Server Client --> ACK --> Server Abrupt close = RST: One RST terminates immediately Check why (application crash? timeout? firewall?)

TCP Stream Reconstruction

Right-click any TCP packet > Follow > TCP Stream to see the entire conversation reconstructed as a continuous data stream. This is invaluable for understanding what data was actually exchanged, especially for text protocols like HTTP.

Analyzing DNS Traffic

DNS issues are extremely common and often cause 'the network is slow' complaints (DNS timeout adds seconds to every new connection). Packet capture reveals exactly what's happening with name resolution. Display Filter: dns DNS Query/Response Pattern: Query: 192.168.1.100 -> 8.8.8.8: Standard query A www.example.com Response: 8.8.8.8 -> 192.168.1.100: Standard query response A www.example.com A 93.184.216.34 What to Look For in DNS:

DNS Analysis Patterns
Pattern	Filter	Meaning
Many queries, no responses	`dns.qry.name`	DNS server unreachable or blocking
Response with no answer	`dns.count.answers == 0`	NXDOMAIN (name doesn't exist)
Single query, multiple responses	Compare transaction IDs	Possible DNS spoofing
High query time	Check timestamp delta	Slow DNS server
Query to unexpected server	Check destination IP	Misconfigured DNS or DNS hijacking
PTR queries flooding	`dns.qry.type == 12`	Something doing reverse lookups excessively

DNS Response Codes:

Code	Name	Meaning
0	NOERROR	Success
1	FORMERR	Format error
2	SERVFAIL	Server failed
3	NXDOMAIN	Name doesn't exist
5	REFUSED	Server refused query

Filter by response code: dns.flags.rcode == 3 (NXDOMAIN) Wireshark DNS Dissection: Expand the DNS protocol in packet details to see: Transaction ID (matches query to response) Flags: Query/Response, Recursion Desired/Available Questions: What was asked Answers: What was returned Authority: Authoritative nameservers Additional: Extra records (glue records, etc.) Example Analysis Workflow: Filter dns to see only DNS traffic Look for unanswered queries (query without matching response) Check response codes for errors Note response times (time between query and response packets) Verify responses contain expected IP addresses

DNS Filters

Wireshark Display Filters

# All DNS traffic
dns
 
# DNS queries only
dns.flags.response == 0
 
# DNS responses only
dns.flags.response == 1
 
# Specific domain
dns.qry.name == "www.example.com"
dns.qry.name contains "example"
 
# NXDOMAIN responses
dns.flags.rcode == 3
 
# A record queries
dns.qry.type == 1
 
# AAAA (IPv6) record queries
dns.qry.type == 28
 
# MX record queries
dns.qry.type == 15
 
# PTR (reverse) queries
dns.qry.type == 12
 
# DNS over specific port (non-standard)
dns and !udp.port == 53

DNS Timeouts Add Up

If you see DNS queries with no responses, note that most resolvers wait 1-5 seconds before retrying or failing. Multiple failed queries in a row can cause perceived delays of 15+ seconds before an application sees an error. This often manifests as 'the website is slow to load.'

Analyzing HTTP/HTTPS Traffic

Web traffic analysis is a core packet capture skill. While HTTPS encrypts the payload, you can still learn a lot from connection patterns. HTTP (Unencrypted) Analysis: Display filter: http HTTP Request Fields: GET /api/users HTTP/1.1 Host: api.example.com User-Agent: Mozilla/5.0... Accept: application/json Cookie: session=abc123 Useful HTTP Filters:

HTTP Analysis Filters

Display Filters

# All HTTP traffic
http
 
# HTTP requests only
http.request
 
# HTTP responses only
http.response
 
# Specific methods
http.request.method == "GET"
http.request.method == "POST"
http.request.method == "PUT"
 
# Response codes
http.response.code == 200
http.response.code == 404
http.response.code == 500
http.response.code >= 400    # All errors
http.response.code >= 500    # Server errors only
 
# URL filtering
http.request.uri contains "/api/"
http.host == "api.example.com"
http.host contains "example"
 
# Content type
http.content_type contains "json"
http.content_type contains "html"
 
# User agent
http.user_agent contains "Mozilla"
http.user_agent contains "curl"

Analyzing Request/Response Pairs: Filter to http.request or http.response Right-click a request > Follow > HTTP Stream See complete request and response together Common HTTP problems in captures:

Symptom	What You See	Likely Cause
Slow page load	Large response, multiple requests	Unoptimized page, many resources
Page timeout	Request, no response (or delayed)	Server overloaded or crashed
4xx errors	400/401/403/404 responses	Client error, auth issue, missing resource
5xx errors	500/502/503/504 responses	Server error, overload, timeout
Redirect loops	Multiple 301/302 in sequence	Misconfigured redirects

HTTPS/TLS Analysis: HTTPS encrypts the payload, but you can still see: IP addresses (source/destination) Port numbers (typically 443) TLS handshake (version negotiation, cipher selection) SNI (Server Name Indication) - the hostname in Client Hello Certificate information (in some cases) Connection patterns (timing, sizes) TLS Filters: tls # All TLS traffic tls.handshake # Handshake messages only tls.handshake.type == 1 # Client Hello tls.handshake.type == 2 # Server Hello tls.handshake.extensions_server_name # SNI hostname ssl.alert_message # TLS alerts (errors) TLS Troubleshooting:

Problem	What You See	Cause
Version mismatch	Client Hello with old version, server RST	Server doesn't support client's TLS version
Cipher mismatch	Handshake failure alert	No common cipher suite
Certificate error	Certificate alert	Expired, wrong hostname, untrusted CA
Slow handshake	Large time gaps between handshake packets	Server overload or network latency

Decrypting HTTPS

You can decrypt HTTPS in Wireshark if you have the TLS session keys. Browsers like Chrome/Firefox can export these keys (set SSLKEYLOGFILE environment variable). Then configure Wireshark: Edit > Preferences > Protocols > TLS > (Pre-)Master-Secret log filename. This is essential for debugging HTTPS issues in development environments.

Capture Best Practices

Effective packet capture requires planning. The difference between a useful capture and a useless one is often preparation. Before Capturing:

Pre-Capture Checklist

•Define the problem — What specific behavior are you trying to capture?
•Identify endpoints — What IPs/ports should you filter on?
•Choose capture point — Client, server, or network device?
•Estimate duration — Short burst or sustained capture?
•Plan storage — Do you have space for the expected capture size?
•Coordinate reproduction — Can you trigger the problem on demand?
•Document environment — Record IP addresses, hostnames, topology

Capture Point Selection:

Capture At	Pros	Cons
Client	See exactly what client sends/receives	May lack visibility to network issues
Server	See what server receives/sends	May miss client-side network issues
Switch (SPAN port)	See transit traffic	Adds complexity, may drop packets under load
Firewall/Router	See traffic at network boundary	Limited to what passes through that point
Both ends	Complete picture	Requires coordination, more data to analyze

Filter Strategy: Capture filters: Use when you know exactly what traffic you need and want to limit file size Display filters: Use when exploring or when you need to see multiple traffic types from same capture Start broad, narrow down: Better to capture too much and filter later than miss the critical packet Dealing with Large Captures:

Large Capture Techniques
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Rotate files after size limit (100MB each, keep 10)
sudo tcpdump -i eth0 -w capture.pcap -C 100 -W 10
 
# Ring buffer: overwrites oldest file when limit reached
sudo tcpdump -i eth0 -w capture.pcap -C 50 -W 5 -Z root
 
# Capture for specific duration (60 seconds)
timeout 60 sudo tcpdump -i eth0 -w capture.pcap
 
# Capture with timestamp in filename
sudo tcpdump -i eth0 -w capture_$(date +%Y%m%d_%H%M%S).pcap
 
# Split capture by packet count
sudo tcpdump -i eth0 -c 10000 -w capture.pcap

Common Mistakes

•Capturing without clear goal
•Forgetting to include timestamps
•Running out of disk space mid-capture
•Capturing on wrong interface
•Not documenting IP-to-hostname mappings
•Truncating packets (old -s 68 default)
•Capturing too long (excessive data)

Best Practices

•Define problem before capturing
•Use ring buffer for long captures
•Check interface selection
•Document environment in notes file
•Include full packets (-s 0)
•Capture at both endpoints when possible
•Save original, work on copy

Sharing Captures

When sharing captures for collaborative troubleshooting: (1) Anonymize if needed (Tools > Statistics > Edit Resolved Name), (2) Filter to relevant traffic only, (3) Include a notes file documenting IPs, issue description, and what to look for. A well-documented capture gets faster help.

Packet Capture

When Packets Don't Lie

Packet Capture Fundamentals

tcpdump - Command-Line Capture

Wireshark - GUI Protocol Analyzer

Analyzing TCP Issues

Analyzing DNS Traffic

Analyzing HTTP/HTTPS Traffic

Capture Best Practices

There’s more to understand.

Packet Capture

When Packets Don't Lie

Packet Capture Fundamentals

tcpdump - Command-Line Capture

Wireshark - GUI Protocol Analyzer

Analyzing TCP Issues

Analyzing DNS Traffic

Analyzing HTTP/HTTPS Traffic

Capture Best Practices

There’s more to understand.