Read a libpcap Savefile Without Guessing What the Bytes Mean

You will finish with a safe way to inspect a classic libpcap .pcap file, identify its format from the first bytes, and explain packet lengths and timestamps without changing the capture. The examples use tcpdump 4.99.4 with libpcap 1.10.4, from Ubuntu package libpcap0.8t64 version 1.10.4-4.1ubuntu3.

Allow about fifteen minutes. You need a shell, a readable capture file, and the installed tcpdump command. Reading an existing file is normally unprivileged. Capturing new traffic may require elevated privileges or extra Linux capabilities, but that is outside this guide.

1. Confirm the tools and preserve the original

Start with read-only checks. They do not require sudo and do not open the capture for writing:

$ command -v tcpdump
/usr/bin/tcpdump
$ tcpdump --version
tcpdump version 4.99.4
libpcap version 1.10.4 (with TPACKET_V3)
$ dpkg-query -W -f='${Package} ${Version}\n' libpcap0.8t64
libpcap0.8t64 1.10.4-4.1ubuntu3

Replace /path/to/capture.pcap in the following commands with the real path. Before using any tool that writes output, make a copy or choose a new destination. Do not use shell redirection onto the only copy of a capture: > truncates its destination before the command has succeeded.

2. Ask libpcap to read the file

Let a libpcap consumer parse the file before inspecting raw bytes. This is the practical test that the file has a recognisable savefile header and records:

$ tcpdump -nn -tttt -r /path/to/capture.pcap
reading from file /path/to/capture.pcap, link-type EN10MB (Ethernet), snapshot length 262144
2026-09-25 18:20:31.123456 IP 192.0.2.10.443 > 192.0.2.20.51000: ...

Your link type, snapshot length, timestamps and packet lines will differ. -r reads an existing file, -nn keeps addresses and ports numeric, and -tttt prints a human-readable date and time. The sample line is illustrative output shape, not a value to expect verbatim.

An empty capture can still be valid: the file header may be present even when there are zero packet records. Conversely, a file that starts with plausible text is not necessarily a pcap file. Treat tcpdump's parser result as the first checkpoint.

3. Inspect the 24-byte file header

The classic savefile header is 24 octets. View only those bytes so that a large capture does not flood the terminal:

$ file /path/to/capture.pcap
/path/to/capture.pcap: pcap capture file, ...
$ xxd -g 1 -l 24 /path/to/capture.pcap
00000000: d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00  ................
00000010: 00 00 04 00 01 00 00 00                          ........

The exact file description and bytes depend on the writer. In this little-endian example, the first four bytes are d4 c3 b2 a1. They represent the normal microsecond format when read by a host using the opposite byte order from the writer. A reader uses the magic value to decide whether multi-byte fields need byte-swapping.

The normal magic value is 0xa1b2c3d4 in the writer's byte order. A related value, 0xa1b23c4d, identifies the same layout with nanoseconds instead of microseconds in packet timestamps. The byte sequence shown above is not a universal signature to paste into a script; byte order matters.

After the magic number come a two-byte major version and a two-byte minor version. The current values documented by the installed manual are major 2 and minor 4. The next four-byte fields are a time-zone offset and timestamp accuracy, both of which should be zero. The final two four-byte fields are the snapshot length and link-layer header type.

4. Interpret snapshot length and packet lengths

The snapshot length is a capture limit, not a promise that every packet is that size. If it is N, a packet longer than N bytes is stored only through its first N bytes. The link-layer type tells libpcap how to interpret the packet's raw beginning; tcpdump normally reports it in the file-reading message.

Each packet record starts with a 16-octet header. It contains four four-byte values: seconds since 1 January 1970 UTC, the fractional part in microseconds or nanoseconds, the number of captured bytes, and the number of bytes that would have existed without snapshot truncation. The captured length is often called caplen; the original length is often called len.

When caplen and len differ, the packet was truncated by the capture limit. That affects analysis: a missing payload may make a protocol decoder stop early, while the original length still records that more data existed. Equal values mean the saved packet was not shortened by the snapshot limit, not that the network packet was necessarily small in every other sense.

Use tcpdump's verbose packet output as a second, operational check rather than manually calculating offsets first:

$ tcpdump -nn -vvv -r /path/to/capture.pcap | head -n 20
reading from file /path/to/capture.pcap, link-type EN10MB (Ethernet), snapshot length 262144
...

The pipe limits display only. It does not alter the capture. If you need to preserve the output for a report, redirect it to a new text file in a directory where you have checked the destination first.

5. Diagnose the common failure modes

If tcpdump says truncated dump file while reading the header, packet header or packet data, the file is shorter than the length fields require. Check its size and compare it with a known-good copy:

$ stat --format='size=%s bytes mode=%A path=%n' /path/to/capture.pcap
size=0 bytes mode=-rw------- path=/path/to/capture.pcap
$ tcpdump -nn -r /path/to/capture.pcap
tcpdump: truncated dump file; tried to read 4 file header bytes, only got 0

Do not repair a damaged capture by inventing lengths or padding it with zeroes. Keep the original, obtain the file again from its producer, or work from a verified backup. If only the final packet is incomplete, some tools may still show earlier records, but that does not make the file complete.

If the parser reports an unknown or unsupported link type, the savefile header may be intact while your installed libpcap lacks the decoder needed for that link-layer value. Record the header and tool versions, then try the file with a compatible libpcap build. Do not silently relabel the link type: that changes how every packet is interpreted.

If a command cannot open the path, check the path and permissions without changing them:

$ test -r /path/to/capture.pcap && echo readable
readable
$ ls -l /path/to/capture.pcap

Use elevated privileges only when the filesystem genuinely requires them, and prefer granting read access to a controlled copy. Root access is not a format decoder and should not be the first response to a parsing error.