Wireshark PCAP Analysis for Network Troubleshooting

A packet capture is the only evidence that cannot lie about what happened on the wire, and yet most engineers open a pcap, scroll for a while and close it. Good analysis is a process: know where the capture must be taken, filter aggressively rather than visually, and read the protocol timeline in the right order. This guide covers that process, including the security-analysis use cases where the same pcap answers questions no log can.

Where to Capture Determines What You Learn

A capture on one host proves what that host saw; a capture on a switch port proves what crossed that port; a capture on the server proves what the application received. Almost every disputed incident is a case of capturing at the wrong point - the client shows no reply, so someone blames the server, when the packet never left the client's rack. Before you capture, decide the question you are answering and whether the host gets to participate in answering it.

Capture, Don't Collect Everything

# Capture filter (-f) limits what is written; display filter limits what is shown
tshark -i eth0 -f "host 10.0.0.5 and tcp port 443" -s 0 -w /tmp/trace.pcap
tshark -i eth0 -f "host 10.0.0.5" -b filesize:51200 -b files:20 -w /tmp/ring.pcap
tcpdump -i eth1 -s 0 -w /tmp/all.pcap 'not port 22'

Use a ring buffer for long-running captures so that older data is overwritten instead of filling the disk - by the time the fault recurs, the interesting packets are still in the buffer. Capture filters use BPF syntax and are applied in the kernel, which is why they keep up with high packet rates where an in-Wireshark filter would not.

Display Filters Worth Memorising

ip.addr == 192.168.1.1
tcp.port == 443 and tcp.flags.syn == 1 and tcp.flags.ack == 0
tcp.analysis.retransmission
tcp.analysis.zero_window
icmp.type == 3
dns.qry.name contains "example"
http.request.method == "GET" and http.response.code >= 400
arp.duplicate-address-detected

tcp.analysis.retransmission and tcp.analysis.zero_window are the two filters that shortcut most performance investigations: the first points at loss, the second at a receiver or application that stopped reading. A green filter bar means valid syntax; red means the expression will not compile and should be fixed before you conclude there are no matching packets.

Reading the Conversation, Not the Packets

Follow the TCP stream to see the application dialogue and reconstruct what was actually sent. Statistics → Conversations sorts endpoints by bytes and packets, which instantly shows which host is dominating the link. Statistics → I/O Graph exposes periodic patterns - a 60-second sawtooth in throughput is an application behaviour, not a network fault. Round-trip time graphs overlay cleanly with retransmissions, which is how you distinguish loss from delay.

Forensic and Security Use Cases

The same tool answers security questions: unencrypted protocols reveal credentials and sessions in plain text, unusual ICMP payloads indicate tunnelling, and 530 responses in FTP traffic indicate repeated authentication failures. Export objects from HTTP and SMB conversations to recover files, and use Statistics → Protocol Hierarchy to spot a protocol that has no business being on that segment.

For encrypted traffic you cannot read inside the session unless you have the keys. TLS can be decrypted with a key log file when the client was started with SSLKEYLOGFILE set; see Wireshark TLS decryption with SSLKEYLOGFILE. Capture filters and display filters are different languages - capture filter vs display filter explains the trap - and command-line analysis at scale is best done with tshark.

Evidence Handling

If the capture may end up in an incident report, record the exact capture point, interface, filter and timestamps, save the file as pcapng so packet comments travel with it, and hash the file when you hand it over. Removing packets from a capture after the fact destroys its evidential value.

原文链接：https://www.wireshark.org/docs/wsug_html/index.html