I can work with this. I think I will use the timestamp heuristic in addition to the checking described below.
Now if I could only get a sample IBM capture file to test with. Thanks for you help and I have no more questions. Cheers, mark.... > -----Original Message----- > From: Guy Harris [mailto:[EMAIL PROTECTED] > Sent: Saturday, September 06, 2003 7:07 AM > To: Mark Bednarczyk > Cc: Tcpdump-Workers > Subject: Re: [tcpdump-workers] Need help to determine capture file > format. > > > 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:[EMAIL PROTECTED]
