Packet capture is the practice of recording network packets exactly as they cross an interface, including headers and usually payload, and storing them with precise timestamps for later analysis. In network monitoring, it is the most detailed source of evidence available, because it shows what was actually sent rather than a summary of it.
Captures are usually written in the pcap or pcapng file format and examined with analyzers such as Wireshark or tcpdump. Where flow records answer who talked to whom, a packet capture answers exactly what was said and when.
How packet capture works
Packet capture works by copying frames from the network stack before or after the operating system processes them. A capture library such as libpcap on Unix-like systems or Npcap on Windows hooks into the driver, applies an optional kernel-level filter and passes matching frames to user space.
Two interface modes decide what the capture can see. In promiscuous mode, a wired adapter accepts frames addressed to other hosts, which matters only where such frames actually arrive. In monitor mode, a wireless adapter records raw 802.11 frames from all nearby networks, including management and control frames.
Each recorded packet carries a timestamp, the captured length and the original length. The snapshot length, or snaplen, limits how many bytes of each packet are stored, which is the main lever for controlling file size and privacy exposure.
Where to capture traffic
The capture point decides which conversations are visible at all. On a switched network, a host only receives its own unicast traffic plus broadcasts, so capturing traffic between two other hosts requires a copy of that traffic. The table compares the usual options.
| Capture point | What it sees | Strength | Weakness |
|---|---|---|---|
| On the endpoint | Traffic of that host only | No extra hardware, sees loopback | Changes the system under test |
| SPAN or mirror port | Copied traffic of chosen ports or VLANs | Uses existing switch features | Drops packets under load, may alter timing |
| Network TAP | Every frame on a physical link | Complete, passive, accurate timing | Requires hardware and a link interruption to install |
| Cloud traffic mirroring | Mirrored traffic of virtual interfaces | Works where no hardware exists | Adds cost and encapsulation overhead |
A frequent mistake is to capture on only one side of a problem. Capturing at both client and server, then comparing the two files, shows whether a packet was lost in transit, delayed, or never sent.
Filters and capture parameters
Capture filters decide what is recorded, while display filters only decide what is shown. Capture filters use the Berkeley Packet Filter (BPF) syntax, such as host 10.0.0.5 and tcp port 443, and are applied in the kernel, so they reduce load and file size. Display filters in Wireshark use a richer syntax and can be changed after the fact.
The parameters below have the largest effect on whether a capture is usable.
| Parameter | Typical setting | What it affects |
|---|---|---|
| Snapshot length | 96 to 128 bytes for headers, 262,144 for full packets | Detail retained versus disk use |
| Ring buffer | For example 20 files of 100 MB | Continuous capture without filling the disk |
| Buffer size | Tens to hundreds of MB | Packet drops during traffic bursts |
| Timestamp precision | Microseconds by default, nanoseconds on capable NICs | Accuracy of latency and jitter measurements |
| Capture filter | BPF expression | Volume and focus of the recording |
Offload features on modern adapters can make captures misleading. With large receive offload or segmentation offload enabled, the capture may show oversized segments or wrong checksums that never appeared on the wire, so these features are often disabled during troubleshooting.
Packet capture compared with flow and counter monitoring
Packet capture sits at the deep end of the monitoring spectrum. Other methods in the same topic trade detail for scale, and an effective monitoring setup usually combines them.
| Method | Data collected | Typical question answered | Storage cost |
|---|---|---|---|
| SNMP counters | Interface totals and errors | Is the link busy or dropping? | Very low |
| NetFlow or IPFIX | Per-flow metadata | Who used the bandwidth? | Moderate |
| Packet capture | Full packets with timestamps | Why did this connection fail? | High |
Packet capture is the method of choice for measuring retransmissions, handshake failures, latency per request and jitter in real-time media, because these effects are visible only in the sequence and timing of individual packets.
Legal, privacy and practical limits
Packet capture can record personal data and credentials in unencrypted protocols, so it is subject to privacy law and internal policy in most organizations. Capturing traffic without authorization may be unlawful, and capture files should be treated as sensitive data with restricted access and defined retention.
- Encryption limits insight: with TLS 1.3 and QUIC, payloads and much of the handshake are opaque without session keys.
- Volume grows quickly: a saturated 10 Gbit/s link produces more than 1 GB of data per second.
- Dropped packets in the capture can look like network loss; the analyzer statistics show whether the capture itself dropped them.
- Clock differences between capture points distort cross-device latency comparisons unless clocks are synchronized.
The idea in brief
A packet capture is like a recording of a phone line instead of a phone bill. The bill tells you who called whom and for how long. The recording lets you hear every word, every pause and every moment the line went quiet.
Network specialists use it when summaries are not enough and they need to see exactly what happened, step by step, to find the cause of a problem.
A practical scenario
Users of an internal web application complained that some page loads froze for about three seconds. Server metrics looked normal, and flow records showed nothing unusual. A network engineer started a ring-buffer capture on the server with a filter for TCP port 443 and a snaplen of 128 bytes, keeping only headers.
When the next freeze was reported, the engineer opened the matching file and saw a burst of TCP retransmissions after exactly one second and again after two more seconds, the classic pattern of exponential backoff. A second capture on the client side proved that the original segments never arrived. The cause turned out to be a firewall dropping packets larger than a misconfigured MTU, and lowering the MSS on the firewall removed the freezes.