tcpdump mailing list archives

Re: Re: [design] test failures in HEAD


From: Guy Harris <guy () alum mit edu>
Date: Tue, 30 Sep 2003 22:50:33 -0700

On Tue, Sep 30, 2003 at 07:58:11PM -0700, Bill Fenner wrote:
 Can we assign them a DLT value, and tell them to get with it?

The backwards compatability bit is tough but at least partially doable; a
trace file captured on OpenBSD with OpenBSD tcpdump may not be decodable
with tcpdump.org's tcpdump.  We assigned DLT 117 to their "old" pflog
type, and they started using DLT 117 for their "new" pflog type, which
we will (probably) assign DLT 143-ish.  libpcap and tcpdump will have
to have different handlers for old and new PFLOG DLTs.

Ethereal currently treats 17 as "old PFLOG" and 117 as "new PFLOG"; when
Can Erkin Acar submitted the patches to do that, I should've said "ask
tcpdump.org for a new value for DLT_PFLOG, we're already using 117" -
I vaguely remember discussing that with him, but I can't find any mail
about it.

I did, however, find some mail that indicated that OpenBSD 3.2's
captures and OpenBSD 3.3's captures are incompatible - the header format
is, I think, the same, but the direction flag values went from 0 = in, 1
= out to 0 = in/out, 1 = in, 2 = out.

The current Ethereal scheme works for OpenBSD 3.4 captures done with the
native libpcap, but not for captures done with tcpdump.org's libpcap.  I
don't know which of those types of captures are more common. 

Using 143 in libpcap makes it unambiguous what type of capture that is,
so we should do that in any case.  We could supply a header-tweaker
program that either overwrites the link layer type value in place, or
copies and changes the link layer type, to fix up captures - there might
be other applications for that.

There's still the cross-platform problem, in that pflog dump files
will have the platform-specific address family in them, but if pflog
is going to exist on more than one platform then that's just going
to be a fact of life.

If the only address family values are AF_INET and AF_INET6, we can
handle that by treating 24, 28, and 30 as all meaning AF_INET6 - OpenBSD
and NetBSD use 24, FreeBSD uses 28, and Darwin/Mac OS X uses 30.  (We
already do that for DLT_NULL, which has the same problem.)
-
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: