tcpdump mailing list archives
Re: Need help to determine capture file format.
From: Guy Harris <guy () alum mit edu>
Date: Sat, 6 Sep 2003 04:06:39 -0700
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
Current thread:
- Need help to determine capture file format. Mark Bednarczyk (Sep 05)
- Re: Need help to determine capture file format. Guy Harris (Sep 06)
- RE: Need help to determine capture file format. Mark Bednarczyk (Sep 06)
- Re: Need help to determine capture file format. Guy Harris (Sep 06)
- RE: Need help to determine capture file format. Mark Bednarczyk (Sep 06)
- RE: Need help to determine capture file format. Mark Bednarczyk (Sep 06)
- Re: Need help to determine capture file format. Guy Harris (Sep 06)