Hack University - Wireshark Troubleshooting Patterns Cheatsheet & Reference

Triage Order

Open an unfamiliar capture in this order. Each step either finds the problem or rules out a whole class of cause.

1. Statistics → Capture File Properties. Duration, packet count, and dropped packets. Drops invalidate everything after this step. 2. Analyze → Expert Information. Errors and warnings first. 3. Statistics → Protocol Hierarchy. Is the traffic you expected even here? 4. Statistics → Conversations, sorted by bytes. Who is talking, and how much. 5. Filter to the one conversation that matters, tcp.stream == N. 6. Follow → TCP Stream or the tcptrace graph, depending on whether the question is "what was said" or "how fast".

capinfos -c -a -e -y -x cap.pcapng
tshark -r cap.pcapng -q -z expert
tshark -r cap.pcapng -q -z io,phs
tshark -r cap.pcapng -q -z conv,ip

Connection Failures

The failure mode is written in the first three packets.

What you see	Diagnosis
SYN, then SYN/ACK, then ACK	Connection established. The problem is above TCP
SYN, then RST/ACK from the server	Port closed, nothing is listening
SYN, then nothing, then SYN retries at 1s, 2s, 4s	Silently dropped. A firewall with a DROP rule, or a routing black hole
SYN, then ICMP type 3 code 3	Port unreachable, usually UDP or a host with no listener
SYN, then ICMP type 3 code 13	Administratively prohibited, an explicit filter told you so
SYN/ACK with no matching SYN	Asymmetric routing, or your capture started late
RST mid-stream from the client	The application closed hard, or a proxy timed out
RST mid-stream from the server	Backend crashed, idle timeout, or a load balancer draining
Repeated SYN on the same 4-tuple	Port reuse, `tcp.analysis.reused_ports`

tcp.flags.syn == 1 and tcp.flags.ack == 0        # every attempt
tcp.flags == 0x014                               # RST/ACK, the refusal
tcp.flags.reset == 1                             # every reset
icmp.type == 3                                   # destination unreachable
icmp.type == 3 and icmp.code == 13               # admin prohibited
tcp.analysis.retransmission and tcp.flags.syn == 1   # SYN never answered

# Which destinations never completed a handshake
tshark -r cap.pcapng -T fields -e ip.dst -e tcp.dstport \
  -Y "tcp.flags.syn==1 && tcp.flags.ack==0" | sort -u > tried.txt
tshark -r cap.pcapng -T fields -e ip.src -e tcp.srcport \
  -Y "tcp.flags.syn==1 && tcp.flags.ack==1" | sort -u > answered.txt
comm -23 tried.txt answered.txt

Slow, But Working

Slowness is one of four things, and each has a signature.

Signature	Cause	Filter
Large `tcp.analysis.ack_rtt` throughout	Latency. Distance or a congested hop	`tcp.analysis.ack_rtt > 0.1`
Retransmissions and duplicate ACKs	Packet loss. Congestion window keeps collapsing	`tcp.analysis.flags`
`ZeroWindow` from the receiver	The receiving application is not reading fast enough	`tcp.analysis.zero_window`
`Window Full` from the sender	Bandwidth-delay product exceeds the window. Scaling is the fix	`tcp.analysis.window_full`
A one-second gap before the response	The server was thinking. Not a network problem	`tcp.time_delta > 1 and tcp.len > 0`
Small `tcp.len` on every packet	Nagle interacting with delayed ACK, or a chatty protocol	`tcp.len > 0 and tcp.len < 100`
High `dns.time` before every connection	Name resolution, not the transfer	`dns.time > 0.2`

Measuring RTT properly:

# Handshake RTT per connection, SYN to SYN/ACK
tshark -r cap.pcapng -T fields -e tcp.stream -e tcp.analysis.ack_rtt \
  -Y "tcp.flags.syn == 1 && tcp.flags.ack == 1"

# Distribution of ACK RTT across the file
tshark -r cap.pcapng -T fields -e tcp.analysis.ack_rtt \
  -Y "tcp.analysis.ack_rtt" | sort -n | awk '{a[NR]=$1} END {
    print "p50", a[int(NR*0.5)]; print "p95", a[int(NR*0.95)];
    print "max", a[NR] }'

# Server think time inside each stream
tshark -o tcp.calculate_timestamps:TRUE -r cap.pcapng \
  -T fields -e tcp.stream -e tcp.time_delta \
  -Y "tcp.len > 0 && tcp.time_delta > 0.5"

tcp.time_delta requires the TCP preference Calculate conversation timestamps, so the -o tcp.calculate_timestamps:TRUE override above is not optional.

Packet Loss That Is Not Real

Before blaming the network, prove the capture is trustworthy. A capture point that drops packets manufactures every symptom of loss.

- Capture drops. capinfos and the status bar report them. Raise -B, use dumpcap rather than the GUI, write to a fast local disk. - Checksum offload. Outbound packets captured on the sending host show bad checksums because the NIC has not filled them in yet. Disable the Validate the … checksum preferences. - Snaplen truncation. [Packet size limited during capture] in the Info column means you captured headers only. Reassembly and Follow Stream will look broken. - Only one direction captured. A SPAN session set up on one direction makes every ACK vanish, so the analysis flags fire constantly. Check Statistics → Conversations for a conversation with zero packets one way. - TSO and LRO. Hardware segmentation offload shows frames larger than the MTU on the capturing host. They never appeared on the wire that way, so ignore the frame sizes and the apparent MSS. - Merged multi-interface capture. Timestamps interleave incorrectly. Run reordercap first.

_ws.malformed
frame.len > 1514 and not tcp.segments        # offload artifact on the host
tcp.checksum.status == "Bad"
tcp.analysis.lost_segment

DNS, DHCP, and ARP Problems

# DNS
dns.flags.rcode == 2        # SERVFAIL
dns.flags.rcode == 3        # NXDOMAIN
dns.time > 0.5              # slow resolver
dns.flags.truncated == 1    # response too big for UDP, should retry over TCP
dns.qry.name and !dns.flags.response   # queries with no answer captured

# DHCP
dhcp                        # the whole exchange, Discover, Offer, Request, Ack
dhcp.option.dhcp == 6       # NAK, the server refused the requested address
dhcp.hw.mac_addr == 00:1a:2b:3c:4d:5e

# ARP
arp.opcode == 1             # requests
arp.duplicate-address-detected     # two hosts claiming one IP
arp.dst.proto_ipv4 == 10.0.0.5     # who is asking for this address

Duplicate address detection and gratuitous ARP explain most "the network went weird for thirty seconds" reports. Wireshark flags the duplicate itself, so a filter on arp.duplicate-address-detected finds it immediately.

# Which MAC claims which IP, and whether any IP has two claimants
tshark -r cap.pcapng -T fields -e arp.src.proto_ipv4 -e arp.src.hw_mac \
  -Y "arp" | sort -u | awk '{print $1}' | uniq -d

Sharing a Finding

A capture is evidence, so trim it to the point and keep it readable.

# Just the conversation, with a comment explaining what to look at
tshark -r big.pcapng -Y "tcp.stream == 12" -w evidence.pcapng \
  --capture-comment "Server sends RST 30s after the last request"

# A time window plus a filter, when the stream is huge
editcap -A "2026-09-15 14:20:00" -B "2026-09-15 14:21:00" big.pcapng win.pcapng
tshark -r win.pcapng -Y "ip.addr == 10.0.0.5" -w evidence.pcapng

# A text transcript for a ticket, no pcap attachment needed
tshark -r evidence.pcapng -t ad -Y "tcp.flags.reset==1 or http" \
  -T fields -e frame.time -e ip.src -e ip.dst -e _ws.col.info

Before sending a file, check what is in it. File → Export Objects shows every recoverable file, Edit → Discard All Secrets removes embedded decryption keys, and a full-payload capture of an internal network contains credentials, tokens, and personal data. Strip the payload with editcap -s 96 when the headers are enough to make the point.