How to compare PCAP files before and after a network change
A useful comparison controls the conditions first. Otherwise a longer capture, a busier user population or a different observation point can look like a regression that the change never caused.
1. Design the comparison before collecting
Use the same capture point, interface, direction, capture filter, snap length and approximate test duration. Repeat the same workload where possible. Record software versions, configuration state and the precise change time.
A defensible pair might be “five minutes from the application host during the same synthetic transaction, immediately before and after the proxy change.” Two arbitrary captures from different weekdays are a weak basis for causation.
A simultaneous capture from an unaffected service or path helps distinguish your change from a wider load spike, DNS issue or upstream event.
2. Compare in layers
Start broad and move toward the reported symptom:
- Capture identity: duration, packet count, bytes and observed rate.
- Protocol mix: unexpected growth or disappearance of a protocol.
- Endpoints: new, missing or newly dominant addresses.
- Conversations: changes in destination, direction or volume.
- Application metadata: DNS names, HTTP hosts and methods, TLS SNI.
- Symptoms: retransmissions, resets, failed handshakes, DNS errors or response timing.
Wireshark statistics can be copied as CSV or JSON for an external diff. tshark is helpful when you want identical commands for both files:
tshark -r before.pcapng -q -z endpoints,ip -z conv,tcp
tshark -r after.pcapng -q -z endpoints,ip -z conv,tcp3. Normalise unequal captures
Do not compare raw packet counts when one capture lasts twice as long. At minimum, calculate packets per second and bytes per second. For a specific transaction, compare equivalent stages or windows rather than the entire file.
Ratios can also be more meaningful than totals:
- TCP resets per completed connection
- Retransmitted segments per TCP data packet
- DNS errors per response
- HTTP 5xx responses per request
Be explicit about the denominator and the detector or display filter used. Different tools may count symptoms differently.
4. Look for new and missing dependencies
A route, proxy, DNS or firewall change often alters who communicates rather than simply how much. Compare destination IPs, DNS queries, TLS server names and HTTP hosts. A new address may be expected service discovery, failover or CDN selection; a missing address may mean successful consolidation or a failed request path.
Changes in protocol distribution deserve the same caution. More DNS packets could mean a resolver problem, a shorter cache lifetime, more clients, or merely a longer capture.
5. Validate the delta at packet level
Once a difference aligns with the reported symptom, isolate the comparable conversation in both files. Check:
- Connection setup and teardown
- Request-to-response timing
- Sequence and acknowledgement progress
- DNS resolution immediately before the connection
- Server selection and TLS negotiation
A summary delta is a lead. The surrounding packets and synchronized observations are what support a causal explanation.
Manual method vs PCAPNG Analyzer
Manual method
- Collect controlled before and after files.
- Run the same Wireshark or tshark statistics on each.
- Export and normalise the results.
- Identify meaningful deltas.
- Inspect equivalent streams in both captures.
With PCAPNG Analyzer
- Analyse both captures.
- Select exactly two completed files in History.
- Open Compare Selected.
- Review totals, protocol counts, IP changes, TCP flags, DNS, HTTP and TLS SNI deltas.
- Account for duration, then validate relevant packets.
The comparison view presents raw values and deltas. It does not prove that the network change caused them, and unequal capture durations still require you to normalise the figures.
Keep before-and-after reports together
Capture comparison is included in the Free tier and runs on your own server.
Start freeView sample report