From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1761.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc1761.txt (limited to 'doc/rfc/rfc1761.txt') diff --git a/doc/rfc/rfc1761.txt b/doc/rfc/rfc1761.txt new file mode 100644 index 0000000..20720ee --- /dev/null +++ b/doc/rfc/rfc1761.txt @@ -0,0 +1,339 @@ + + + + + + +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. + + + + + + + + + + + + + + + + +Callaghan & Gilligan [Page 1] + +RFC 1761 Snoop Packet Capture File Format February 1995 + + +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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Callaghan & Gilligan [Page 2] + +RFC 1761 Snoop Packet Capture File Format February 1995 + + + 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 + + + +Callaghan & Gilligan [Page 3] + +RFC 1761 Snoop Packet Capture File Format February 1995 + + + 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. + + + + + + +Callaghan & Gilligan [Page 4] + +RFC 1761 Snoop Packet Capture File Format February 1995 + + + 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. + + + + + + + +Callaghan & Gilligan [Page 5] + +RFC 1761 Snoop Packet Capture File Format February 1995 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Callaghan & Gilligan [Page 6] + -- cgit v1.2.3