Sounds great!
I'm going to try it out right away.
marc.
Guy Harris wrote:
>
> > 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).