How to Reduce a PCAP File for Analysis (editcap & tshark)

Why you can throw most of the file away

A capture of a file transfer is mostly the file. The bytes that make it huge are the payload — the document being copied, the disk image being pulled, the backup being streamed. But the first question about a slow transfer — is the network losing or stalling packets? — is not answered by the payload. It is answered by the TCP control information wrapped around it: retransmissions, duplicate ACKs, zero-window stalls, round-trip time, resets. That metadata sits in the first few dozen bytes of every packet, and for that question it is all you need.

So there are two levers. You can keep every packet and throw away the payload (a snapshot-length trim), or you can keep full packets but only for the one conversation or time window that matters. Often the smallest, cleanest file comes from doing both.

Lever 1 — strip the payload with editcap -s

This is the fastest win and the one to reach for first. editcap -s sets a snapshot length — a hard cap on how many bytes of each packet to keep. Cap it just past the headers and you keep every packet, every timestamp, and every retransmission while discarding the payload that makes the file enormous.

editcap -s 128 big.pcap trimmed.pcap

128 bytes leaves room for Ethernet, IP (with options), and TCP (with options) plus a few bytes beyond; drop to 96 for pure TCP-performance work. On a transfer-heavy capture this routinely removes 80–95% of the size — a 130 MB file becomes a few megabytes — with zero loss of timing or retransmission data.

The original capture: full-size frames, every payload byte still on the wire.

After editcap -s 128. Wireshark notes [Packet size limited during capture] — expected and harmless: the sequence numbers, ACKs, window sizes, and retransmissions are all still there.

Wireshark flagging frames as “truncated” is not an error — it is confirmation the trim worked. Check the new size any time with capinfos trimmed.pcap.

Lever 2 — keep only the conversation that matters

If you know the two endpoints, slice the capture down to just their traffic with a display filter and tshark:

tshark -r big.pcap -Y "ip.addr==172.31.1.78 && ip.addr==172.31.1.89" -w trimmed.pcap

Add && tcp.port==5985 to narrow to a single service. To cut by time instead — you usually know roughly when it stalled — editcap takes a window:

editcap -A "2026-06-19 14:00:00" -B "2026-06-19 14:02:00" big.pcap trimmed.pcap

Or by packet range with editcap -r big.pcap trimmed.pcap 1-200000. For the smallest possible file, chain the two levers: isolate the conversation first, then strip its payloads.

What the trimmed capture still tells you

Here is the test. We took the payload-stripped capture from Lever 1 — a slow WinRM (Windows Remote Management) session between a server on 172.31.1.78:5985 and a client on 172.31.1.89, cut from 1.3 MB to 192 kB — and dropped it into PcapAI in Troubleshooting mode. In Wireshark the capture looks like a lossy link: 580 of its 1,488 frames are flagged [TCP Retransmission], 36–40% of every connection. PcapAI’s report on the same trimmed file finds no network problem at all.

PcapAI’s executive summary of the trimmed capture: no network problems found in 20 checks across 11 areas, network impact 0/100.

Both tools read the same headers; they disagree about what the headers mean. Every flagged frame is a byte-for-byte copy of the frame just before it — same IP ID, same sequence number, same length — captured 1 to 181 microseconds later. Nothing was resent: a real retransmission follows a timer or duplicate ACKs, and the resent segment is a new IP packet with a new IP ID. The capture point recorded every data frame twice; the classic causes are a SPAN session that mirrors the same traffic from two ports and a capture on a teamed or virtual-switch interface. PcapAI counts a frame captured twice once, so its report shows zero retransmissions and 0.0% estimated loss, and the network is cleared instead of blamed.

That verdict came out of the headers alone, so the trim cost nothing there. It did cost one thing: the full-size original also lets PcapAI time the WinRM server’s answers — a median 503 ms to first byte over 138 requests, a Low-severity finding it assigns to the server. The trimmed file cannot measure that: its HTTP messages are cut off at 128 bytes per frame, and the report lists the 1,160 cut frames under its limitations. That is the deal trimming offers: snaplen-trim when the question is “is the network losing packets?”, and keep full packets for one conversation (Lever 2) when the question is “is the server slow to answer?”

Quick reference

• Strip payloads, keep all packets: editcap -s 128 big.pcap trimmed.pcap — the first thing to try for any network-performance question.
• Keep one conversation: tshark -r big.pcap -Y "ip.addr==A && ip.addr==B" -w trimmed.pcap
• Keep a time window: editcap -A "start" -B "end" big.pcap trimmed.pcap
• Split into fixed chunks: editcap -c 100000 big.pcap chunk.pcap — writes one file per 100k packets.
• Check the result: capinfos trimmed.pcap

All of these ship with Wireshark on every platform, so there is nothing extra to install. Once the file is down to size, the same trimmed capture is what surfaces problems like TCP retransmission storms — in a fraction of the time the full file would take.