Re: [WinPcap-users] MAC ADDRESS pcap_if_t

[Guy Harris <guy () alum mit edu>]

On Mon, Aug 04, 2003 at 11:55:05AM +0200, Loris Degioanni wrote:
> In my opinion, storing the MAC address inside the pcap_if_t structure could
> be a useful feature, currently I'm adding somthing similar in packet.dll.
> However, this mailing list is not the right place to request it, since
> pcap_if_t is a structure defined by libpcap, that is included in WinPcap but
> that is maintained at www.tcpdump.org.

Actually, as it's an interface address, the right place to store it is,
arguably, in the list of addresses attached to a "pcap_if_t".

In fact, that is where it is, at least on some BSD systems, as an
address of type AF_LINK.

However, that can be implemented only if the OS on which libpcap is
running has an AF_LINK address type, or if libpcap supplies one; not all
of the OSes necessarily supply one, and, if libpcap supplies one,
there's a risk that it'll choose a number that conflicts with one the OS
either uses now, or uses later.

In addition, the BSD AF_LINK addresses correspond to "struct
sockaddr_dl" structures, which we'd also have to define on platforms
that don't define one; that structure, at least in FreeBSD 3.4, is

/*
 * Structure of a Link-Level sockaddr:
 */
struct sockaddr_dl {
        u_char  sdl_len;        /* Total length of sockaddr */
        u_char  sdl_family;     /* AF_DLI */
        u_short sdl_index;      /* if != 0, system given index for interface */
        u_char  sdl_type;       /* interface type */
        u_char  sdl_nlen;       /* interface name length, no trailing 0 reqd. */
        u_char  sdl_alen;       /* link level address length */
        u_char  sdl_slen;       /* link layer selector length */
        char    sdl_data[12];   /* minimum work area, can be larger;
                                   contains both if name and ll address */
        u_short sdl_rcf;        /* source routing control */
        u_short sdl_route[16];  /* source routing information */
};
  
#define LLADDR(s) ((caddr_t)((s)->sdl_data + (s)->sdl_nlen))

which includes a bunch of additional stuff to supply.

So that might not be the right place to put it.

Unfortunately, changing the layout of a "pcap_if_t" arguably changes the
ABI of "pcap_findalldevs()"; we could add stuff at the end, meaning a
new version of the library won't cause problems for an old application
that doesn't expect that stuff (as long as adding stuff at the end
doesn't change the alignment in memory of any of the other elements in
the structure), but an application expecting a new version of the
library won't work correctly with the old version.

We could have a "pcap_findalldevs_ex()" - but WinPcap already has one,
with the existing "pcap_if_t" structure.  So we could have a
"pcap_findalldevs_ex_ex()" - but that's ugly, and the *next* time we add
a per-interface attribute, you have to do "pcap_findalldevs_ex_ex_ex()",
which is beginning to sound as if it comes from "The Frogs" by
Aristophanes. :-)

I'd been thinking about adding some other per-interface information, and
decided that if I do that, the right way to do it would be to add a
"pcap_findalldevs_proplist()", or something such as that, with the
"pcap_if_t" structure replaced by a structure containing a "next"
pointer, a possibly-empty set of hard-wired properties, and either a
chunk of memory containing a list of properties as an attribute/value
list, along with the length of that chunk of memory, or a linked list of
those properties - with network-layer addresses (IPv4 and possibly IPv6,
at least) being among those properties.

That way, to add a new property, we'd just define a new numerical value
for the property, and add it to the list.  Programs that know about the
new property just won't get that property when run with the old library;
they should be prepared not to get that property, and fail or work
around the absence of the new property.  Programs that don't know about
a particular property should just ignore it.

(CCed to tcpdump-workers, and replies set to tcpdump-workers; WinPcap
users who want to participate are welcome, but, as Loris noted, this is
a libpcap issue, not a WinPcap-specific issue, so it's probably best
discussed in the mailing list for tcpdump and libpcap.)
-
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