tcpdump mailing list archives

New APIs to support multiple DLT_'s on an interface


From: Guy Harris <gharris () sonic net>
Date: Wed, 11 Dec 2002 15:03:03 -0800

On Mon, Nov 11, 2002 at 02:36:04PM -0600, David Young wrote:
Just FYI, I have patched NetBSD's tcpdump for multiple tap types.
-L lists available DLTs.  -D sets a different DLT than the default.

Unfortunately, "-D" was already claimed by WinDump as an option to print
out a list of all available interfaces; the current CVS version of
tcpdump, which has the WinDump code merged in, supports it for that
purpose:

        % tcpdump -D
        1.fxp0
        2.lo0
        % tcpdump -i 1
        tcpdump: listening on fxp0

where the numbers can be used instead of names as an argument to "-i".

That might not be too useful on systems that support "ifconfig -a", but
Windows doesn't *and* doesn't have particularly nice names for
interfaces, and even some UNIXes, e.g. HP-UX as of 11.00, don't support
"ifconfig -a".

The letters available in tcpdump are:

        b g G h H I M o P Q U V W y

Tethereal and Ethereal should probably support the same options, if
possible; one or both of them already uses

        b h o P Q V

leaving

        g G H I M U W y

which is a pretty poor selection, but such are the consequences of the
folks at Bell Labs deciding that single-letter options were the way to
go (perhaps defensible in the days of the PDP-11, but...).  I guess I'd
vote for I, as the letter "interface", as in "network interface", begins
with "I".

NetBSD's libpcap has an API for listing/selecting DLTs, consisting of

  int pcap_list_datalinks(pcap_t *p, int **dlt_buffer)

and

  int pcap_set_datalink(pcap_t *p, int dlt).

What should happen on platforms that don't support multiple link-layer
types per interface?  The options I see are:

        1) don't have the APIs present at all on those platforms;

        2) have them return an error;

        3) have "pcap_list_datalinks()" return a one-element list with
           the "pcap_datalink()" value, and either have
           "pcap_set_datalink()" return an error or return success if
           you're setting the link-layer type to the type it already has
           a failure otherwise.

(In any case, perhaps those APIs should take an additional "char
*errbuf" argument so that if the error *isn't* one returned by a system
call we can still supply an error message.)

The advantage of 1) is that any portable program should be able to deal
with the APIs not being present (so that they work with older versions
of libpcap, e.g. the current tcpdump.org release and the versions in
current Linux distributions and released BSDs), and the way the program
works if it's not running on an OS that lets an interface have multiple
DLT's from which it can choose should probably be the same way as the
way it works if it has an older version of libpcap that doesn't include
APIs to get the list or choose a DLT_ from the list.

The disadvantage of 1) is that we'd have to duplicate
"pcap_list_datalinks()" in other libpcaps for other platforms that can
support it.  Is there some reason why the NetBSD libpcap gets the list
of DLTs at open time, and "pcap_list_datalinks()" just presents one from
the list, rather than getting the list from the driver in
"pcap_list_datalinks()"?  If we did that, there'd be no duplication of
that sort, although "pcap_set_datalink()" wouldn't be able to check if
the DLT_ value to be used is in the list; however, presumably BIOCSDLT
would fail if the DLT_ value wasn't valid, anyway, so I'm not sure what
the advantage is of having it check the list first.

If we don't go with 1), I'm not sure whether 2) or 3) is better.  2)
means that "-L" and "-D" or "-I" or whatever can report an error on
platforms that don't let you choose a DLT_ value, whereas 3) means that
you (the user) don't have to worry about what platform you're on, those
options will do something at least semi-sensible even on platforms that
don't let you choose a DLT_ value.
-
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: