How to use packet captures safely and deliberately

Counters, flows and traces are all summaries. Packet capture is not: it records the actual bytes on the wire, which puts it at the most detailed and most expensive end of the evidence spectrum. For unencrypted protocols, that includes headers and payload content. For TLS-encrypted traffic, it captures the handshake and the encrypted ciphertext; without the session keys, the payload content is opaque.

What packet capture usually reveals, regardless of encryption: source and destination IP addresses, source and destination port numbers, packet timing, sizes, and visible transport behaviour such as TCP flags and sequence numbers. TLS 1.3 encrypts the server certificate after the early handshake. SNI is still visible in many deployments, but Encrypted Client Hello can hide the real ClientHello and SNI where it is deployed. QUIC goes further by encrypting most transport control information that TCP exposes. Capture is still highly informative for connectivity and performance questions, but its visibility boundary is narrower on modern encrypted protocols.

Packet capture does not reveal application semantics from encrypted traffic. It cannot tell you what an HTTPS response contained, only that a response arrived and how large it was. For questions about application-level correctness on encrypted traffic, you need application-level logging, not packet capture.

QUIC is worth stating precisely, because it is where the habits built on TCP stop working. Above the UDP header, a capture of an established QUIC connection shows connection IDs, packet lengths and arrival times, and very little else. RFC 9000 applies header protection to the packet number and encrypts the frames that carry acknowledgements, flow-control updates and stream data, so the sequence numbers, retransmissions and window sizes that a TCP capture hands you for free are not there to read. Connection migration closes the remaining gap: when a client changes network, RFC 9000 expects it to use a fresh connection ID precisely so that an observer cannot tie the new path to the old one. A passive capture of QUIC answers "did packets flow, in what volume, with what timing" and stops.

ECH removes the other thing a capture could still be relied on for. The server name has always travelled in clear text in the ClientHello, which is why a capture on a shared address could say which site was being visited even though everything after the handshake was encrypted. RFC 9849 encrypts that first message under a public key published for the hosting provider. Where ECH is deployed, the capture shows a connection to an address that may serve thousands of names, an outer name belonging to the provider, and nothing that identifies the site the user asked for.

None of this makes capture useless. It moves the capture point. On the wire between client and server there is less every year, so the evidence has to be taken where the bytes are still in the clear: at the host, where the capture happens before the transport encrypts or after it decrypts and where a browser key log turns a capture back into readable HTTP; at a terminating proxy or load balancer, where one leg of the connection is already decrypted; or at the resolver, whose query log answers the naming question that ECH took off the wire. Each point sees a different slice and none sees all of it, so choosing where to capture is now most of the work. Choosing what to capture is the rest of it, and that is a filter.

tcpdump is the standard command-line packet capture tool on Linux and macOS. It uses the Berkeley Packet Filter (BPF) engine to apply filters at the kernel level, before packets are passed to userspace. This is the capture filter: it determines which packets are collected at all. A precise capture filter reduces the volume of data written to disk and minimises performance impact on the host.

BPF filter expressions combine primitives with boolean operators. The primitive host 192.168.1.1 matches any packet where either source or destination is that address. tcp port 443 matches TCP traffic on port 443 in either direction. tcp port 443 and host 192.168.1.1 combines them. The not operator excludes traffic: not port 22 avoids capturing the SSH session running tcpdump, which would otherwise create recursive capture noise.

Saving to a file uses the -w flag: tcpdump -i eth0 -w capture.pcap tcp port 443. Reading a saved file for inspection uses -r. Limiting capture size prevents disk exhaustion on busy links: -C 100 rotates to a new file every 100 MB, and -W 5 limits it to five rotation files (a ring buffer). That combination is what lets a capture sit running for days waiting for an intermittent fault, on a known and bounded amount of disk.

One filter, applied once, at collection time: that is the whole of tcpdump's filtering story, and it is why the expression has to be right before the capture starts. A graphical analyser adds a second filter that runs afterwards on packets already recorded. The two look similar on the screen and behave nothing alike.

Wireshark is a graphical packet analyser that uses the same libpcap engine as tcpdump for capture. It introduces a second filtering layer that tcpdump does not have: the display filter. Understanding the distinction between them prevents a common mistake.

A capture filter in Wireshark uses BPF syntax and is applied at capture time. Only packets matching the filter are recorded. If you apply a capture filter and then decide you needed different traffic, you must start a new capture. The syntax is the same as tcpdump: tcp port 443, host 10.0.0.1.

A display filter is applied after capture. It hides or shows packets already recorded without discarding them. Display filters use Wireshark's own protocol-aware syntax, which is richer: http.response.code == 200, tcp.flags.syn == 1,dns.qry.name contains "example.com". Changing a display filter is instant and reversible; all packets remain in the capture buffer.

The practical workflow is: use a broad capture filter to minimise volume, capture for a defined time window, then use display filters to explore the captured data. Do not try to make the capture filter so narrow that it answers your question; that is what display filters are for. Both of them operate on the same thing: the file the capture wrote. What that file records beyond the raw bytes decides what a colleague can still work out from it a week later, and what you are handing over when you send it.

The pcap format (libpcap format) is the original packet capture file format. It stores a global header with link-layer type and snapshot length, followed by per-packet records containing a timestamp, captured length, original length, and packet bytes. Every tool in the network analysis ecosystem can read pcap files, making them the universal exchange format for captured traffic.

pcapng (pcap Next Generation) extends pcap with richer metadata. A pcapng file can record multiple capture interfaces in a single file, include interface descriptions, record interface statistics, embed comments on individual packets, and store custom application blocks. When Wireshark saves a capture, it uses pcapng by default. When tcpdump saves a capture, it produces pcap. Both formats are readable by both tools.

The snapshot length (snaplen) controls how many bytes of each packet are captured. The default is typically 262,144 bytes (enough for any Ethernet MTU). Reducing snaplen to 96 bytes captures headers only, which is sufficient for connectivity and routing questions while significantly reducing file size and avoiding inadvertent capture of payload data.

That last point is not a storage optimisation. Payload bytes on disk are a record of other people's traffic, and they carry obligations that outlast the incident: who was allowed to authorise the collection, how long the file may be kept, and who may open it. The final section deals with those obligations, because they are the part of capture practice that a technically perfect filter cannot fix.

Packet capture on a production network is not a routine debugging step. It creates a record of all network activity within its scope, which may include credentials, session tokens, personal data, and privileged business communications. In many jurisdictions, intercepting network communications without authorisation is a criminal offence. In the UK, the Computer Misuse Act 1990 and the Investigatory Powers Act 2016 are relevant; in the EU, GDPR Article 5 governs the principle of data minimisation.

Before capturing traffic on any production or shared network, confirm: you have written authorisation from the system or network owner; the capture scope is limited to the minimum necessary to answer the question; the capture duration is defined and bounded; captured files are handled according to data classification policy and deleted when no longer needed. On shared infrastructure such as cloud environments, the authorisation question extends to the cloud provider's acceptable use policy.

Operationally, running tcpdump on a busy interface consumes CPU and can affect latency on high-traffic hosts. Wireshark running in promiscuous mode on a production host with high packet rates can cause packet loss in the capture itself. Use the -s 96snaplen limit and precise capture filters to reduce this impact. For links above 1 Gbps, hardware-assisted capture (network TAPs, SPAN ports with dedicated capture hardware) is the safer approach.