Re: Extra DLT types required for opensolaris DLPI DL

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

On Mar 27, 2009, at 7:01 PM, Sebastien Roy wrote:

> The only hitch is that DL_IPNET devices behave like DLT_RAW by  
> default.
> The DL_IOC_IPNET_INFO ioctl enables the inclusion of the "ipnet"  
> header.
> The thinking here was that with a tiny modification to libpcap,  
> existing
> applications that understand DLT_RAW could read packets off of  
> DL_IPNET
> devices.  The downside is that we now can't really have libpcap turn  
> on
> DL_IOC_IPNET_INFO if such applications assume that these devices are
> DLT_RAW.

libpcap-based applications assume that devices with a link-layer type  
of DLT_RAW are DLT_RAW.  They don't see the DLPI DL_ type (unless they  
reach around libpcap and fetch it directly, but those applications are  
sufficiently non-portable, and are probably doing something they don't  
really need to do, so I'm really not inclined to care about them), so  
they aren't in a position to make assumptions about that type.  If  
libpcap returns a DLT_ value other than DLT_RAW, they won't assume the  
device supplies DLT_RAW headers (unless they're so badly written that  
I don't care whether they break).

Currently, libpcap doesn't understand DL_IPNET; nothing prevents it  
from, on DL_IPNET devices:

        1) doing the ioctl to turn on the ipnet header;

        2) returning some new DLT_ value.

The only thing that would break would be applications that don't  
understand that new DLT_ value, but that happens with *any* new DLT_  
value.

Alternatively, libpcap could have DL_IPNET devices offer *two* new  
link-layer types, defaulting to DLT_RAW, but also offering the new  
DLT_ value, and if the application requests the new DLT_ value,  
libpcap would do the ioctl.  That mechanism was originally put into  
libpcap to support a BSD mechanism for selecting different DLT_ values  
and link-layer headers for different BPF devices referring to the same  
underlying network interface, presumably so that 802.11 devices could  
supply 802.11 headers without breaking applications that didn't know  
about them (by defaulting to DLT_EN10MB).

However:

> Perhaps it would be simpler if we got rid of DL_IOC_IPNET_INFO
> and had DL_IPNET devices always include the header.

I'd prefer the simplest solution; getting rid of DL_IOC_IPNET_INFO is  
the simplest, with hiding it in libpcap and offering only the new DLT_  
being the next-simplest.  Offering a choice either means

	1) requiring users to request the link-layer type they want, which is  
probably not going to be the default choice for loopback devices

or

	2) having the application know about those types of devices and know  
that the new DLT_ is to be preferred to DLT_RAW if it's available.

(At some point Wireshark, at least, will probably do something such as  
2) for 802.11 devices; it probably should have done that since Day  
One.  I guess the lack of full filtering support for radiotap headers  
in earlier versions of libpcap did mean that the choice between 802.11  
and 802.11+radiotap was useful at one point.)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.