Re: Need help to determine capture file format.

[Guy Harris <guy () alum mit edu>]

On Sat, Sep 06, 2003 at 06:58:34AM -0400, Mark Bednarczyk wrote:
> I did not know about the IBM special case. I guess that the only way to
> determine if the file is the special case by heuristics of the time stamp
> value? (Ie. if the micro-seconds are 1000 times off of reasonable values,
> then must be IBM patch file format). Is there another way you've used?

To quote the comment in Ethereal's "wiretap/libpcap.c":

        /*
         * AIX's non-standard tcpdump uses a minor version number of 2.
         * Unfortunately, older versions of libpcap might have used
         * that as well.
         *
         * The AIX libpcap uses RFC 1573 ifType values rather than
         * DLT_ values in the header; the ifType values for LAN devices
         * are:
         *
         *      Ethernet        6
         *      Token Ring      9
         *      FDDI            15
         *
         * which correspond to DLT_IEEE802 (used for Token Ring),
         * DLT_PPP, and DLT_SLIP_BSDOS, respectively.  The ifType value
         * for a loopback interface is 24, which currently isn't
         * used by any version of libpcap I know about (and, as
         * tcpdump.org are assigning DLT_ values above 100, and
         * NetBSD started assigning values starting at 50, and
         * the values chosen by other libpcaps appear to stop at
         * 19, it's probably not going to be used by any libpcap
         * in the future).
         *
         * We shall assume that if the minor version number is 2, and
         * the network type is 6, 9, 15, or 24, that it's AIX libpcap.
         *
         * I'm assuming those older versions of libpcap didn't
         * use DLT_IEEE802 for Token Ring, and didn't use DLT_SLIP_BSDOS
         * as that came later.  It may have used DLT_PPP, however, in
         * which case we're out of luck; we assume it's Token Ring
         * in AIX libpcap rather than PPP in standard libpcap, as
         * you're probably more likely to be handing an AIX libpcap
         * token-ring capture than an old (pre-libpcap 0.4) PPP capture
         * to Ethereal.
         */

The most complete code I know of for coping with the many variants of
libpcap format that use the standard magic number but that aren't
standard (as well as the one that uses the "patched" magic number but
has the extra debugging stuff) is the Ethereal code; it uses some
heuristics that are harder to do in a library such as libpcap that has
to support reading from a pipe (so that it can't just try reading
several packets under one assumption about the header format and, if
that fails, seeking backward and reading the packets under another
assumption), and does the AIX hack above (which we could probably do in
libpcap as well, although it runs the risk of mis-identifying some older
libpcap formats as AIX format).

One goal of the new format I mentioned in my previous message would be
to allow the format to be extended in ways that older code that doesn't
know about the extensions can still handle, by having a section of TLVs
in the file header and the per-packet header - older code can just skip
over, or copy, TLVs it doesn't understand.  Hopefully this will reduce
the number of developers who feel the need to enhance the format in an
incompatible fashion, and thus the number of developers who feel that
need but don't realize that if they do so they should change the magic
number....
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe