After the file header, a PCAP file is a run of packet records, one per captured packet, up to the end of the file. There is no count and no index: a reader takes one record after another. Each record is a 16-byte header and then the bytes of the packet.
Record header
Numbers are unsigned, in the byte order the file header’s magic number shows.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
0 | 4 | uint32 | Timestamp, seconds | When the packet was captured, in seconds since 1 January 1970 00:00:00 UTC. |
4 | 4 | uint32 | Timestamp, fraction | Microseconds (0 to 999,999) or nanoseconds (0 to 999,999,999) after that second, as the file header’s magic number says. |
8 | 4 | uint32 | Captured packet length | The number of packet bytes stored after this header: the smaller of the original length and the file’s SnapLen. |
12 | 4 | uint32 | Original packet length | How long the packet was on the wire, before it was cut to the snapshot length. It should not be less than the captured length. |
16 | captured length | bytes | Packet data | The packet, starting with its link-layer header. Its layout depends on the file’s link type. |
Records are not padded, so the next record starts straight after the last byte of packet data and may not be on a 4-byte boundary. In files of version 2.2 and earlier the two length fields are the other way round; see versions.
When the file header’s FCS bits say the link has a frame check sequence, that many bytes at the end of the packet data are the FCS, and they count in both lengths.
Modified format
Files with the magic number 0xA1B2CD34, from Alexey Kuznetsov’s patches
to Linux’s capture tools, have a 24-byte record header. The first 16 bytes are as above;
the packet data starts at offset 24.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
0 | 16 | – | Standard header | Seconds, microseconds, captured length and original length, as above. |
16 | 4 | uint32 | Interface index | The index of the network interface the packet was captured on. |
20 | 2 | uint16 | Protocol | The Ethernet packet type. |
22 | 1 | uint8 | Packet type | Which way the packet went; see below. |
23 | 1 | – | Padding | Unused. |
| Packet type | Meaning |
|---|---|
| 0 | Sent to the capturing machine |
| 1 | Broadcast by another machine |
| 2 | Multicast by another machine |
| 3 | Sent from one other machine to another |
| 4 | Sent by the capturing machine |
A version of this format from SuSE Linux 6.3 (the ss990915 patches) keeps the
protocol and packet type but replaces the padding with two fields that Wireshark calls
CPU 1 and CPU 2. Wireshark’s notes say their meaning is unknown, and this page does not
give their exact layout.
Example
The first record of a little-endian, microsecond capture, straight after the 24-byte file header. The marked bytes are the record header; the rest is the start of an Ethernet frame.
00000018 00 F1 53 65 40 E2 01 00 3C 00 00 00 3C 00 00 00 ..Se@...<...<...
00000028 FF FF FF FF FF FF 00 11 22 33 44 55 08 06 00 01 ......."3DU....Reading it: seconds 0x6553F100, 1,700,000,000, which is 14 November 2023
22:13:20 UTC; microseconds 0x0001E240, 123,456; captured length and
original length both 60, so the whole packet was kept and the next record starts at
0x18 + 16 + 60 = 0x64. The packet begins with the Ethernet broadcast address, the
sender’s address 00:11:22:33:44:55 and the EtherType 0x0806,
ARP.