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:
- RE: proposed tcpdump dinner @IETF55, (continued)
- RE: proposed tcpdump dinner @IETF55 Fulvio Risso (Nov 12)
- Re: proposed tcpdump dinner @IETF55 Bill Fenner (Nov 11)
- Re: proposed tcpdump dinner @IETF55 David Young (Nov 11)
- Re: proposed tcpdump dinner @IETF55 Michael Richardson (Nov 11)
- Re: proposed tcpdump dinner @IETF55 David Young (Nov 11)
- Re: proposed tcpdump dinner @IETF55 Guy Harris (Nov 13)
- Re: proposed tcpdump dinner @IETF55 Michael Richardson (Nov 18)
- Re: proposed tcpdump dinner @IETF55 itojun (Nov 18)
- Re: proposed tcpdump dinner @IETF55 Michael Richardson (Nov 19)
- Re: proposed tcpdump dinner @IETF55 David Young (Nov 11)
- Re: proposed tcpdump dinner @IETF55 Michael Richardson (Nov 18)
- New APIs to support multiple DLT_'s on an interface Guy Harris (Dec 11)
- Re: New APIs to support multiple DLT_'s on an interface Guy Harris (Dec 11)
- Re: New APIs to support multiple DLT_'s on an interface Guy Harris (Dec 19)
- Re: New APIs to support multiple DLT_'s on an interface David Young (Dec 11)
- Re: New APIs to support multiple DLT_'s on an interface Guy Harris (Dec 11)
- Re: New APIs to support multiple DLT_'s on an interface Guy Harris (Dec 17)
- Re: New APIs to support multiple DLT_'s on an interface Darren Reed (Dec 18)
- Re: New APIs to support multiple DLT_'s on an interface Guy Harris (Dec 18)
- Re: New APIs to support multiple DLT_'s on an interface Darren Reed (Dec 18)
- Re: New APIs to support multiple DLT_'s on an interface Guy Harris (Dec 18)
- Re: New APIs to support multiple DLT_'s on an interface Darren Reed (Dec 18)