How to Analyze a PCAP

To analyze a PCAP quickly, spend the first 15 minutes on orientation, not on individual packets. Check what the file contains with capinfos, read the Protocol Hierarchy, Conversations, and Expert Information views in Wireshark, then run a handful of starter display filters to find failures. By the end you should know what the capture covers, which flows matter, and which question to investigate next.

This is the quick start. If you already know the incident and need the full method, from capture validation through hypothesis testing and reporting, use the practical PCAP analysis workflow.

The 15-minute plan

The point of the time box is discipline. A PCAP can absorb hours of scrolling. Fifteen minutes of structured orientation usually tells you whether the file can answer the question at all.

Minute 0 to 2: write the question and check the file

Before opening Wireshark, write one sentence: who saw what problem, and roughly when. "Client 10.1.4.22 could not reach the payroll service around 09:40" is enough. Without it, every retransmission looks interesting.

Then check the file itself. capinfos ships with Wireshark and prints a compact summary:

capinfos capture.pcapng

Look at four things:

• Earliest and latest packet time. Does the window include the reported time? Mind the time zone.
• Number of packets and duration. A two-second capture of a five-minute problem is a warning.
• Packet size limit (snaplen). If packets were sliced at 96 or 128 bytes, headers are visible but application payload is not.
• Interfaces and encapsulation. Multiple interfaces or unusual link types change how you read direction and duplicates.

In Wireshark, Statistics > Capture File Properties shows the same facts, plus any capture comments and, for some capture tools, dropped-packet counts. If the file does not cover the incident window, stop here and ask for a better capture.

Minute 2 to 5: Protocol Hierarchy

Open Statistics > Protocol Hierarchy. It shows the share of packets and bytes per protocol, nested by encapsulation. You are looking for surprises:

• Is the application protocol you expect present at all?
• Is almost everything TLS, which means payload analysis will depend on metadata and timing?
• Are there tunnels such as VXLAN, GRE, or IPsec that hide the inner traffic?
• Is a large share of traffic something unrelated, such as backups or broadcast noise?

The equivalent in TShark:

tshark -r capture.pcapng -q -z io,phs

Protocol Hierarchy is an inventory, not a diagnosis. A high share of one protocol is normal in many networks.

Minute 5 to 8: Conversations and Endpoints

Open Statistics > Conversations and switch between the IPv4, TCP, and UDP tabs. Sort by bytes, then by packets, then by duration. Find the conversation that matches your question: the affected client, the service address, or the port.

Statistics > Endpoints gives the same view per host. Unexpected heavy talkers, a client that talks to many hosts on one port, or a server that never answers are all worth noting.

TShark equivalents:

tshark -r capture.pcapng -q -z conv,tcp
tshark -r capture.pcapng -q -z conv,udp
tshark -r capture.pcapng -q -z endpoints,ip

From the Conversations window you can right-click a row and apply it as a filter. That single step usually turns a 200,000-packet capture into a few hundred relevant frames.

Minute 8 to 11: Expert Information

Open Analyze > Expert Information. Wireshark groups dissector observations by severity: errors, warnings, notes, and chats. Typical entries include malformed packets, TCP retransmissions, duplicate ACKs, zero windows, resets, and "previous segment not captured".

Read it as a list of leads:

• Errors often point to malformed packets or dissector problems worth checking first.
• Warnings such as resets, zero windows, or missing segments narrow where to look.
• "Previous segment not captured" can mean real loss or a capture gap. Do not treat it as proof of network loss.

tshark -r capture.pcapng -q -z expert

Expert Information labels are heuristics from the dissectors. They tell you where Wireshark noticed something unusual, not why it happened. The TCP retransmission analysis guide explains how to tell real loss from capture artifacts.

Minute 11 to 14: starter display filters

These display filters find the most common failure signs. Run them one at a time and note how many packets match.

tcp.flags.syn == 1 && tcp.flags.ack == 0
tcp.flags.reset == 1
tcp.analysis.flags && !tcp.analysis.window_update
dns.flags.rcode != 0
http.response.code >= 400
tls.handshake.type == 1
icmp.type == 3

What each one shows:

• SYN without ACK: connection attempts. Compare with the number of completed handshakes to spot unanswered connects.
• Reset: connections that were refused or aborted. Check who sent the reset.
• TCP analysis flags: retransmissions, duplicate ACKs, zero windows, and similar transport events, without the noisy window updates.
• DNS rcode not zero: failed lookups such as NXDOMAIN or SERVFAIL.
• HTTP 400 and above: client and server errors in cleartext HTTP.
• TLS ClientHello: every TLS connection attempt, with the server name in the handshake where visible.
• ICMP destination unreachable: routing, filtering, or port problems reported by the path.

Every filter also works in TShark. Adding fields makes the output easier to scan:

tshark -r capture.pcapng -Y 'tcp.flags.reset == 1' \
  -T fields -e frame.number -e frame.time_relative \
  -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport

tshark -r capture.pcapng -Y 'tls.handshake.type == 1' \
  -T fields -e frame.number -e ip.dst -e tls.handshake.extensions_server_name

tshark -r capture.pcapng -Y 'dns.flags.rcode != 0' \
  -T fields -e frame.number -e dns.qry.name -e dns.flags.rcode

When a filter points to an interesting flow, right-click a packet and use Follow > TCP Stream to see the conversation in order, or filter on tcp.stream == N to keep only that stream.

Minute 14 to 15: write down what you know

Close the quick start with four short notes:

1. Coverage: time window, capture point if known, snaplen, and any obvious gaps.
2. Relevant flows: addresses, ports, and tcp.stream numbers that match the question.
3. Leads: frame numbers for resets, failed lookups, retransmissions, or errors.
4. Next question: the one thing you will check next, such as "why does stream 14 wait 4 seconds after the request?"

Frame numbers matter. A lead that says "frames 812 to 815" can be reopened by anyone. A lead that says "some resets" cannot.

Common quick-start mistakes

• Starting with packet one. Scrolling from the top of the file is the slowest way to find anything.
• Trusting totals. Thousands of retransmissions across a whole file can come from one unrelated backup job.
• Ignoring the capture boundary. A one-sided capture or sliced packets limit what you can conclude.
• Treating Expert Information as a verdict. It is a set of observations, not a root cause.
• Uploading production captures without thinking. If you plan to share the file with a vendor or an AI service, sanitize it first with a tool such as Anoncap.

Where to go next

After 15 minutes you should have a narrow question and a short list of flows. Pick the path that fits:

• Full workflow: the practical PCAP analysis workflow covers timelines, competing hypotheses, exact evidence, and reporting.
• Slow application: start with how to troubleshoot slow applications to decide whether packets are even the right first data source.
• Suspicious traffic: the guide to finding malicious traffic in a PCAP adds IDS alert triage, DNS and TLS correlation, command-and-control checks, and file validation.
• Very large files: analyzing large PCAP files covers capture-wide inventories, narrowing, and session indexing when Wireshark becomes slow.
• AI assistance: can Wireshark use AI for packet analysis explains realistic options and their limits.

For a guided first pass, the PacketSafari Analyzer runs capture-wide Triage over a selected PCAP and returns ranked signals linked to their matching frames, so the orientation step starts from exact packet evidence. Wireshark and TShark remain the tools for unrestricted manual inspection, and the habits above apply whichever tool you open first.