> Wow. Congratulations on being able to wedge in even more heuristics
> for the cornucopia of libpcap formats.
Hopefully, the following comment, which I checked into "pcap-int.h" in
the libpcap CVS tree, right in front of the declaration of the
per-packet header structure (and a similar comment in "pcap.h" in front
of the declaration of the file header structure) will, at least when the
next libpcap/tcpdump releases come out, discourage people from changing
the file format without getting a new magic number:
/*
* How a `pcap_pkthdr' is actually stored in the dumpfile.
*
* Do not change the format of this structure, in any way (this includes
* changes that only affect the length of fields in this structure),
* and do not make the time stamp anything other than seconds and
* microseconds (e.g., seconds and nanoseconds). Instead:
*
* introduce a new structure for the new format;
*
* send mail to "tcpdump-workers@xxxxxxxxxxx", requesting a new
* magic number for your new capture file format, and, when
* you get the new magic number, put it in "savefile.c";
*
* use that magic number for save files with the changed record
* header;
*
* make the code in "savefile.c" capable of reading files with
* the old record header as well as files with the new record header
* (using the magic number to determine the header format).
*
* Then supply the changes to "patches@xxxxxxxxxxx", so that future
* versions of libpcap and programs that use it (such as tcpdump) will
* be able to read your new capture file format.
*/
(although I've no idea how quickly people will pick up the new libpcap;
there are probably a ton of people who still think the right place to
get libpcap and tcpdump from is LBL, not tcpdump.org).