After the 16-byte file header come the packet records, one per packet, in the order captured, to the end of the file. Each is a 24-byte header, the packet data and some padding. All numbers are unsigned 32-bit big-endian.
Record header
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
0 | 4 | uint32 | Original length | The packet’s length as received from the network. |
4 | 4 | uint32 | Included length | Bytes of the packet stored in this record. Less than the original length only when the packet was cut short. |
8 | 4 | uint32 | Packet record length | The length of the whole record: 24, plus the included length, plus the padding. The next record starts this many bytes after this one. |
12 | 4 | uint32 | Cumulative drops | Packets the capturing system lost between the first record of the file and this one. Software that cannot count losses writes 0, so 0 does not prove nothing was lost. |
16 | 4 | uint32 | Timestamp seconds | When the packet arrived, in seconds since 1 January 1970. |
20 | 4 | uint32 | Timestamp microseconds | The microseconds after that second. |
24 | included length | bytes | Packet data | The packet, starting with the header of the file’s datalink type. |
| … | varies | bytes | Pad | Zero or more bytes padding the record “out to a convenient boundary”, in RFC 1761’s words; the RFC does not set their values. Wireshark writes zeros up to a 4-byte boundary, and its reader notes captures with 4 and with 6 bytes of padding. |
For Ethernet, Wireshark assumes a snoop (not Shomiti) file has no frame check sequence.
ATM pseudo-header
With datalink type 18 (DL_IPATM), Solaris puts 4 bytes in front of each
packet. This layout is from Wireshark’s reader, not from RFC 1761.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
0 | 1 | uint8 | Flags | Bit 0x80 gives the direction. The low 4 bits are the traffic type: 1 LANE, 2 RFC 1483 LLC-multiplexed, 3 MARS, 4 IFMP, 5 ILMI, 6 signalling. |
1 | 1 | uint8 | VPI | Virtual path identifier. |
2 | 2 | uint16 | VCI | Virtual channel identifier. |
The cells are AAL5, except signalling: traffic type 6, or VPI 0 with VCI 5.
Shomiti trailer
Captures from Shomiti (later Finisar) Surveyor keep a 16-byte trailer in each record’s padding, and their Ethernet frames include the 4-byte FCS. Wireshark takes a file to be from Surveyor when the first record’s padding is at least 16 bytes. The fields, from Wireshark’s source, which does not use them:
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
0 | 2 | uint16 | phy_rx_length | Length on the wire. |
2 | 2 | uint16 | phy_rx_status | Status flags such as overflow, bad CRC, short or oversize frame, good frame. The bit values are not published. |
4 | 4 | uint32 | ts_40_ns_lsb | Low half of a timestamp in units of 40 ns. |
8 | 4 | uint32 | ts_40_ns_msb | High half of that timestamp. |
12 | 4 | int32 | frame_id | A frame number. |
Example
The first record of an Ethernet capture, straight after the file header. The marked bytes are the record header.
00000010 00 00 00 3C 00 00 00 3C 00 00 00 54 00 00 00 00 ...<...<...T....
00000020 65 53 F1 00 00 01 E2 40 FF FF FF FF FF FF 00 11 eS.....@........Reading it: original and included length 60; record length 0x54, 84, which is
24 + 60 with no padding; no drops; seconds 0x6553F100, 1,700,000,000,
14 November 2023 22:13:20 UTC; microseconds 123,456. The Ethernet frame starts at 0x28
with the broadcast address, and the next record at 0x10 + 84 = 0x64.