[Guy Harris <gharris@xxxxxxxxx>]

On Tue, Mar 26, 2002 at 12:01:24AM -0500, Benoit Galarneau wrote:
> When I write a packet with tcpdump or ethereal, there is an D4 C3 B2
> A1 preambule before the first MAC address. 
> 
> I would like to know more about this D4 C3 B2 A1... preambule.

That's the file header.  Many capture file formats have such a header.

The header of libpcap-format files (as used by tcpdump, Ethereal,
Analyzer, and a number of other programs) contains:

	a 32-bit "magic number";

	a 16-bit major version number;

	a 16-bit minor version number;

	an unused 32-bit time zone offset field;

	an unused 32-bit time stamp accuracy field;

	a 32-bit field giving the maximum length of the saved data in
	    packets;

	a 32-bit field giving the link-layer type of the packets in the
	    capture.

All numbers are in the same byte order, which is typically the byte
order of the machine that wrote the capture file.

The magic number has the value hex A1B2C3D4.  On a big-endian machine,
such as a SPARC machine, the four bytes of that number are A1, B2, C3,
and D4, in order.  On a little-endian mchine, such as a PC, the four
bytes of that number are D4, C3, B2, and A1, in order.

That number serves two purposes:

	1) it indicates that the file is a libpcap-format file;

	2) it indicates the byte order of the numbers in the file header
	   and the header written in front of the packet data.

If, when a program or library routine reads the file header, the number
is hex A1B2C3D4, the other numbers in the header are in the byte order
of the machine reading the file, and do not need to be byte-swapped. 
If, however, it's D4C3B2A2, they're in the opposite byte order of the
machine reading the file, so the program or library routine needs to
byte-swap them.

The current major and minor version numbers for libpcap-format files are
2 and 4, respectively.

The two unused fields are set to 0 by libpcap (as used by tcpdump and
many other programs) and the internal library Ethereal uses to write
capture files.  I don't know whether they were ever used.

The maximum length of the saved data in packets is the "snapshot length"
specified when the capture was done, e.g. with "-s" for tcpdump or
Tethereal, and "-s" or the appropriate dialog box option for Ethereal,
causing no more than that many bytes of packet data to be saved to the
file.

The link-layer type is a number specifying the type of link-layer
headers in the capture, e.g. Ethernet, FDDI, Token Ring, etc..

Following that header are a sequence of records, one per packet.  Each
record consists of a per-packet header followed by the raw packet data.

The per-packet header contains:

	a time stamp, consisting of 2 32-bit numbers, giving the time
	the packet arrived, in seconds since January 1, 1970, 00:00:00
	GMT in the first number, and microseconds since the second in
	question in the second number;

	a 32-bit number giving the number of bytes of data for that
	packet that are in the file;

	a 32-bit number givin the number of bytes of data that were in
	the packet - this could be larger than the previous number.

So the data before the first MAC address, in an Ethernet capture,
consists of *two separate* pieces:

	1) the per-file header;

	2) the per-packet header.

There is only one per-file header, at the beginning of the file.  There
is one per-packet header before *each* packet's data.

Note that libpcap includes routines to read and write these files, so
one rarely needs to know the details of this - if you want to write a
program to read or write those files, you should try to use the libpcap
routines to read them ("pcap_open_offline()", "pcap_loop()",
"pcap_close()") or to write them ("pcap_dump_open()", "pcap_dump()",
"pcap_dump_close()") if you can.