A practical PCAP triage checklist
Good triage reduces a large capture to a defensible scope: where it was recorded, what time it covers, which systems dominate it, and which symptoms deserve packet-level investigation.
Upload the capture and PCAPNG Analyzer does the first pass of this checklist for you: a good, warning or poor rating for DNS, TCP and HTTP; the top talkers and conversations; the devices and services it found; and, in Pro, findings that explain what they mean and what to check next. Read on to see what that pass involves, and for the questions only you can answer.
Just one capture to check? The free PCAP Toolkit does the DNS, TCP and HTTP ratings and the top talkers in your browser, without uploading the file.
See network health in a sample report →1. Preserve the original and its context
Before filtering, splitting or converting anything, keep an untouched copy. Record the capture point, interface, collection filter, start time, time zone, snap length and whether hardware offload was enabled. Without that context, an apparently missing packet may be a capture limitation rather than a network failure.
Create a hash if the capture is evidence or will be shared between investigators:
sha256sum incident.pcapngWork from a copy and avoid distributing a capture casually. Packet payloads can contain credentials, session data, internal hostnames and personal information.
2. Check whether the capture is usable
Start with file metadata rather than assumptions. Wireshark's capinfos reports format, packet count, duration, data rate, snap length and interface information:
capinfos incident.pcapngCheck for a suspiciously short duration, truncated packets, unexpected interfaces, implausible timestamps or a collection rate that could have overwhelmed the capture host or SPAN port. A cleanly readable file can still be incomplete.
If a packet is missing, it may have been dropped by the network, filtered before capture, lost by the capture process, or observed on a different path. State what the capture shows before claiming what the network did.
3. Establish the traffic baseline
Answer five questions before chasing individual packets:
- How long does the capture run, and are there quiet gaps?
- Which protocols account for most packets and bytes?
- Which source and destination addresses are most active?
- Which endpoint pairs dominate the conversations?
- Which DNS names, HTTP hosts and TLS server names are visible?
Useful tshark summaries include:
tshark -r incident.pcapng -q -z io,phs
tshark -r incident.pcapng -q -z endpoints,ip
tshark -r incident.pcapng -q -z conv,tcpHigh volume is not automatically suspicious. Backups, software distribution, telemetry and video can dominate a healthy network. Compare results with the purpose of the segment and the reported incident window.
4. Look for symptoms, not verdicts
Use broad checks to form hypotheses:
- Name resolution: repeated queries, NXDOMAIN responses, long response times or unexpected resolvers.
- TCP health: retransmissions, duplicate acknowledgements, resets, incomplete handshakes and zero-window advertisements.
- Traffic shape: bursts, periodic connections, unusual destination concentration or a new high-volume endpoint.
- Application clues: clear-text HTTP error codes, unfamiliar hostnames, visible TLS SNI and certificate metadata.
- Layer 2: ARP changes, floods or duplicate address symptoms when the capture point can see them.
Then narrow by time, endpoint and conversation. A global count cannot explain causality. Inspect packets immediately before and after the event, and compare both directions of the flow.
5. Separate observations from conclusions
A useful incident note distinguishes three things:
- Observed: “The capture contains 18 client retransmissions between 14:02:11 and 14:02:14.”
- Inferred: “Loss or severe reordering on the path after this capture point is plausible.”
- Needed next: “Collect a synchronized server-side capture and interface counters.”
This wording prevents a heuristic, an Expert Information entry or a dashboard count from being mistaken for proof.
Manual method vs PCAPNG Analyzer
Manual method
- Run capinfos and record capture context.
- Open Wireshark statistics for protocols, endpoints and conversations.
- Apply symptom-oriented display filters.
- Follow relevant streams and inspect timing.
- Save filtered subsets or export fields for reporting.
With PCAPNG Analyzer
- Upload the capture, or drop it into a watched folder (Pro).
- Read the health verdict and the findings: each says what it means, when it’s usually harmless and what to check next (findings are Pro).
- Drill into talkers, conversations, streams or packets for the ones that matter, and export JSON, CSV or an incident report.
One upload produces the whole first pass: capture summary, protocol mix, talkers and conversations, DNS, HTTP and TLS breakdowns, network health and devices, plus Pro findings that explain themselves. What it can’t know is your context: whether a host is authorised, whether the capture point missed traffic, or whether a flagged pattern is expected on your network. That judgement stays with you.
Make the first pass repeatable
Generate the same structured overview for every capture on infrastructure you control.
Download freeView sample report