Summary

  • RFC 1761 gave other programs a way to read and write Sun's Snoop Version 2 packet captures, separating collection from later analysis.
  • Each record distinguishes the packet's original length from the bytes actually saved; its drop counter can read zero even when the capturing system cannot count losses.

The best thing about a packet capture is that it survives the meeting. A technician can collect traffic now and someone else can examine it tomorrow, perhaps in another program. The worst thing is how readily a crisp file becomes a confident witness. In February 1995, Brent Callaghan and Robert Gilligan described Sun's Snoop Version 2 file format in RFC 1761. Their stated aim was compatibility: other programs could generate and interpret the files. The format also gave a careful reader the means to ask what the file did, and did not, preserve.

Its first 16 bytes do a great deal of work. Eight identify the file as snoop followed by three null bytes. Four carry version 2. Four more choose the datalink type for the packet records: Ethernet has code 4, while IEEE 802.3 has code 0. That distinction is a decoding instruction, not an ornamental label. If a reader treats the wrong link header as the right one, every interpretation above it begins on the wrong foot. The RFC lists several other types, including Token Ring, HDLC and FDDI. All the file's integers are big-endian.

After that header, the file is a sequence of variable-length records. Each starts with six 32-bit values—a 24-byte little interrogation of the captured packet. The first two are especially useful. Original length says how large the packet was when received from the network. Included length says how many of its bytes made it into the file. If the latter is smaller, the packet was truncated for storage. A neatly displayed protocol header cannot restore the tail that was never saved. The packet data begins with its datalink header; the file-level type tells the reader how to decode it.

The next value, total record length, counts the descriptor, saved data and any padding. It tells a parser where the following record begins. Confuse included length with record length and a packet file can turn into a house of mirrors: bytes from padding or the next record acquire a story they never told. The RFC's layout made compatible analysis possible precisely because it gave independent readers the boundaries.

Then comes the field with the most awkward office politics: cumulative drops. It counts packets the capturing system lost between the first record and the current record. Some implementations, the RFC says, cannot count those drops and may write zero. Zero therefore has two possible biographies: no counted losses, or no ability to count. It is a poor basis for announcing that the network was silent in the gaps. Even a nonzero value speaks about the capture system's loss, not automatically about delivery to the intended application.

The final pair records arrival time as seconds since 1 January 1970 plus microseconds. It lets an analyst arrange saved packets in time. It does not turn a stored packet into proof that an application accepted it, that another endpoint received it, or that a fault occurred at the displayed instant. Those are later questions requiring other records. RFC 1761 did not solve every dispute over what happened on a network. It gave the file a readable anatomy and, for anyone paying attention, a surprisingly candid list of its blind spots.