Snoop capture format: Snoop Version 2 Packet Capture File Format
How Sun's snoop tool stores captured network packets on disk, so other programs can read and write the same files.
Callaghan, B. and R. Gilligan, "Snoop Version 2 Packet Capture File Format", RFC 1761, DOI 10.17487/RFC1761, February 1995, <https://www.rfc-editor.org/info/rfc1761>.
@misc{rfc1761,
series = {Request for Comments},
number = 1761,
howpublished = {RFC 1761},
publisher = {RFC Editor},
doi = {10.17487/RFC1761},
url = {https://www.rfc-editor.org/info/rfc1761},
author = {B. Callaghan and R. Gilligan},
title = {{Snoop Version 2 Packet Capture File Format}},
pagetotal = 6,
year = 1995,
month = feb,
} RFC text
Contents
Network Working Group B. Callaghan
Request for Comments: 1761 R. Gilligan
Category: Informational Sun Microsystems, Inc.
February 1995
Snoop Version 2 Packet Capture File Format
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This paper describes the file format used by "snoop", a packet
monitoring and capture program developed by Sun. This paper is
provided so that people can write compatible programs to generate and
interpret snoop packet capture files.
1. Introduction
The availability of tools to capture, display and interpret packets
traversing a network has proven extremely useful in debugging
networking problems. The ability to capture packets and store them
for later analysis allows one to de-couple the tasks of collecting
information about a network problem and analysing that information.
The "snoop" program, developed by Sun, has the ability to capture
packets and store them in a file, and can interpret the packets
stored in capture files. This RFC describes the file format that the
snoop program uses to store captured packets. This paper was written
so that others may write programs to interpret the capture files
generated by snoop, or create capture files that can be interpreted
by snoop.
2. File Format
The snoop packet capture file is an array of octets structured as
follows:
+------------------------+
| |
| File Header |
| |
+------------------------+
| |
| Packet Record |
~ Number 1 ~
| |
+------------------------+
. .
. .
. .
+------------------------+
| |
| Packet Record |
~ Number N ~
| |
+------------------------+
The File Header is a fixed-length field containing general
information about the packet file and the format of the packet
records it contains. One or more variable-length Packet Record
fields follow the File Header field. Each Packet Record field holds
the data of one captured packet.
3. File Header
The structure of the File Header is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification Pattern +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Datalink Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identification Pattern:
A 64-bit (8 octet) pattern used to identify the file as
a snoop packet capture file. The Identification Pattern
consists of the 8 hexadecimal octets:
73 6E 6F 6F 70 00 00 00
This is the ASCII string "snoop" followed by three null
octets.
Version Number:
A 32-bit (4 octet) unsigned integer value representing
the version of the packet capture file being used. This
document describes version number 2. (Version number 1
was used in early implementations and is now obsolete.)
Datalink Type:
A 32-bit (4 octet) field identifying the type of
datalink header used in the packet records that follow.
The datalink type codes are listed in the table below:
Datalink Type Code
------------- ----
IEEE 802.3 0
IEEE 802.4 Token Bus 1
IEEE 802.5 Token Ring 2
IEEE 802.6 Metro Net 3
Ethernet 4
HDLC 5
Character Synchronous 6
IBM Channel-to-Channel 7
FDDI 8
Other 9
Unassigned 10 - 4294967295
4. Packet Record Format
Each packet record holds a partial or complete copy of one packet as
well as some descriptive information about that packet. The packet
may be truncated in order to limit the amount of data to be stored in
the packet file. In addition, the packet record may be padded in
order for it to align on a convenient machine-dependent boundary.
Each packet record holds 24 octets of descriptive information about
the packet, followed by the packet data, which is variable-length,
and an optional pad field. The descriptive information is structured
as six 32-bit (4-octet) integer values.
The structure of the packet record is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Included Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cumulative Drops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp Microseconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Packet Data .
. .
+ +- - - - - - - -+
| | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Original Length
32-bit unsigned integer representing the length in
octets of the captured packet as received via a network.
Included Length
32-bit unsigned integer representing the length of the
Packet Data field. This is the number of octets of the
captured packet that are included in this packet record.
If the received packet was truncated, the Included
Length field will be less than the Original Length
field.
Packet Record Length
32-bit unsigned integer representing the total length of
this packet record in octets. This includes the 24
octets of descriptive information, the length of the
Packet Data field, and the length of the Pad field.
Cumulative Drops
32-bit unsigned integer representing the number of
packets that were lost by the system that created the
packet file between the first packet record in the
file and this one. Packets may be lost because of
insufficient resources in the capturing system, or for
other reasons. Note: some implementations lack the
ability to count dropped packets. Those
implementations may set the cumulative drops value to
zero.
Timestamp Seconds
32-bit unsigned integer representing the time, in
seconds since January 1, 1970, when the packet arrived.
Timestamp Microseconds
32-bit unsigned integer representing microsecond
resolution of packet arrival time.
Packet Data
Variable-length field holding the packet that was
captured, beginning with its datalink header. The
Datalink Type field of the file header can be used to
determine how to decode the datalink header. The length
of the Packet Data field is given in the Included Length
field.
Pad
Variable-length field holding zero or more octets that
pads the packet record out to a convenient boundary.
5. Data Format
All integer values are stored in "big-endian" order, with the high-
order bits first.
6. Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Brent Callaghan
Sun Microsystems, Inc.
2550 Garcia Avenue
Mailstop UMTV05-44
Mountain View, CA 94043-1100
Phone: 1-415-336-1051
EMail: brent.callaghan@eng.sun.com
Robert E. Gilligan
Sun Microsystems, Inc.
2550 Garcia Avenue
Mailstop UMTV05-44
Mountain View, CA 94043-1100
Phone: 1-415-336-1012
EMail: bob.gilligan@eng.sun.com
AI ELI5
On this page
§1Why Capture Files Matter
Tools that capture, display and interpret packets are very useful for debugging network problems. Saving captured packets to a file separates two jobs: collecting information about a problem, and analysing it later.
snoop is a packet monitoring and capture program developed by Sun. This memo describes the file format it uses so that others can write programs that interpret snoop capture files, or create files that snoop can interpret.
If you record a show, you can watch it later instead of live. Snoop records network traffic so people can study it afterwards.
§2File Layout and File Header
A snoop capture file is an array of octets. It starts with a fixed-length File Header, followed by one or more variable-length Packet Records, each holding the data of one captured packet.
The File Header has three parts. The Identification Pattern is 8 octets, 73 6E 6F 6F 70 00 00 00, which is the ASCII string snoop followed by three null octets. The Version Number is a 32-bit unsigned integer; this document describes version 2, and version 1 was used in early implementations and is now obsolete. The Datalink Type is a 32-bit field that says what kind of datalink header the packet records use.
Every recording starts with a label that says 'this is a snoop tape', which version it is, and what kind of network it came from. After the label come the recorded packets, one after another.
- 0IEEE 802.3 — Datalink type code 0.
- 1IEEE 802.4 Token Bus — Datalink type code 1.
- 2IEEE 802.5 Token Ring — Datalink type code 2.
- 3IEEE 802.6 Metro Net — Datalink type code 3.
- 4Ethernet — Datalink type code 4.
- 5HDLC — Datalink type code 5.
- 6Character Synchronous — Datalink type code 6.
- 7IBM Channel-to-Channel — Datalink type code 7.
- 8FDDI — Datalink type code 8.
- 9Other — Datalink type code 9.
- 10 - 4294967295Unassigned — Not assigned.
§3The Packet Record
Each packet record holds a partial or complete copy of one packet and some descriptive information. The packet may be truncated to limit how much is stored, and the record may be padded so it aligns on a convenient machine-dependent boundary.
The descriptive information is 24 octets, made of six 32-bit integers: Original Length (the packet's length as received from the network), Included Length (how much of it is stored; smaller than the original if the packet was truncated), Packet Record Length (the whole record, including the 24 octets, the data and the pad), Cumulative Drops, Timestamp Seconds and Timestamp Microseconds.
Cumulative Drops counts packets lost by the capturing system between the first record in the file and this one. Some implementations cannot count drops and may set it to zero. The timestamp is in seconds since January 1, 1970, plus microseconds. After the six integers comes the Packet Data, beginning with its datalink header, then a Pad of zero or more octets.
Each recorded packet comes with a little tag: how big it really was, how much was saved, how many were missed, and when it arrived. Then comes the packet itself, with a bit of empty space at the end if needed.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
ORIGINAL-LENGTH | Original Length | 4 bytes | Length in octets of the packet as received from the network. | |
INCLUDED-LENGTH | Included Length | 4 bytes | Length of the Packet Data field; less than Original Length if truncated. | |
RECORD-LENGTH | Packet Record Length | 4 bytes | Total record length: 24 octets, packet data and pad. | |
CUMULATIVE-DROPS | Cumulative Drops | 4 bytes | Packets lost since the first record in the file. | |
TS-SECONDS | Timestamp Seconds | 4 bytes | Seconds since January 1, 1970 when the packet arrived. | |
TS-MICRO | Timestamp Microseconds | 4 bytes | Microsecond resolution of arrival time. |
§4Byte Order and Security
All integer values are stored in big-endian order, with the high-order bits first. A reader on any machine must account for this when reading the lengths, counters and timestamps.
The memo's Security Considerations section says only that security issues are not discussed.
When writing a big number, everyone must agree which digit goes first. Snoop always writes the biggest part first. The memo says nothing about safety.