As per Relevance of the word gilligan, we have this rfc below:
Network Working Group B.
Request for Comments: 1761 R.
Category: Informational Sun Microsystems, Inc
February 1995
Snoop Version 2 Packet Capture File
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This paper describes the file format used by "snoop", a
monitoring and capture program developed by Sun. This paper
provided so that people can write compatible programs to generate
interpret snoop packet capture files
1.
The availability of tools to capture, display and interpret
traversing a network has proven extremely useful in
networking problems. The ability to capture packets and store
for later analysis allows one to de-couple the tasks of
information about a network problem and analysing that information
The "snoop" program, developed by Sun, has the ability to
packets and store them in a file, and can interpret the
stored in capture files. This RFC describes the file format that
snoop program uses to store captured packets. This paper was
so that others may write programs to interpret the capture
generated by snoop, or create capture files that can be
by snoop
Callaghan & Gilligan [Page 1]
RFC 1761 Snoop Packet Capture File Format February 1995
2. File
The snoop packet capture file is an array of octets structured
follows
+------------------------+
| |
| File Header |
| |
+------------------------+
| |
| Packet Record |
~ Number 1 ~
| |
+------------------------+
. .
. .
. .
+------------------------+
| |
| Packet Record |
~ Number N ~
| |
+------------------------+
The File Header is a fixed-length field containing
information about the packet file and the format of the
records it contains. One or more variable-length Packet
fields follow the File Header field. Each Packet Record field
the data of one captured packet
3. File
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
a snoop packet capture file. The Identification
consists of the 8 hexadecimal octets
73 6E 6F 6F 70 00 00 00
This is the ASCII string "snoop" followed by three
octets
Version Number
A 32-bit (4 octet) unsigned integer value
the version of the packet capture file being used.
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
datalink header used in the packet records that follow
The datalink type codes are listed in the table below
Datalink Type
------------- ----
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
Each packet record holds a partial or complete copy of one packet
well as some descriptive information about that packet. The
may be truncated in order to limit the amount of data to be stored
the packet file. In addition, the packet record may be padded
order for it to align on a convenient machine-dependent boundary
Each packet record holds 24 octets of descriptive information
the packet, followed by the packet data, which is variable-length
and an optional pad field. The descriptive information is
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
32-bit unsigned integer representing the length
octets of the captured packet as received via a network
Included
32-bit unsigned integer representing the length of
Packet Data field. This is the number of octets of
captured packet that are included in this packet record
If the received packet was truncated, the
Length field will be less than the Original
field
Packet Record
32-bit unsigned integer representing the total length
this packet record in octets. This includes the 24
octets of descriptive information, the length of
Packet Data field, and the length of the Pad field
Callaghan & Gilligan [Page 4]
RFC 1761 Snoop Packet Capture File Format February 1995
Cumulative
32-bit unsigned integer representing the number
packets that were lost by the system that created
packet file between the first packet record in
file and this one. Packets may be lost because
insufficient resources in the capturing system, or
other reasons. Note: some implementations lack
ability to count dropped packets.
implementations may set the cumulative drops value
zero
Timestamp
32-bit unsigned integer representing the time,
seconds since January 1, 1970, when the packet arrived
Timestamp
32-bit unsigned integer representing
resolution of packet arrival time
Packet
Variable-length field holding the packet that
captured, beginning with its datalink header.
Datalink Type field of the file header can be used
determine how to decode the datalink header. The
of the Packet Data field is given in the Included
field
Variable-length field holding zero or more octets
pads the packet record out to a convenient boundary
5. Data
All integer values are stored in "big-endian" order, with the high
order bits first
6. Security
Security issues are not discussed in this memo
Callaghan & Gilligan [Page 5]
RFC 1761 Snoop Packet Capture File Format February 1995
Authors'
Brent
Sun Microsystems, Inc
2550 Garcia
Mailstop UMTV05-44
Mountain View, CA 94043-1100
Phone: 1-415-336-1051
EMail: brent.callaghan@eng.sun.
Robert E.
Sun Microsystems, Inc
2550 Garcia
Mailstop UMTV05-44
Mountain View, CA 94043-1100
Phone: 1-415-336-1012
EMail: bob.gilligan@eng.sun.
Callaghan & Gilligan [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
