Re: Extra DLT types required for opensolaris DLPI DL

[Darren Reed <Darren.Reed () Sun COM>]

On 27/03/09 07:42 PM, Guy Harris wrote:
> ...
>     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).

I've used tcpdump in this fashion on BSD :)
So I was already quite aware of this and counting on it :)


> > 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.

Because of how it must be implemented, it would seem to me that the 
first DLT_ found will always be the hardware one, which is what you 
would see without the funny loopback variation(s), on all devices except 
lo0, so no surprises there.


Darren

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.