Re: Extra DLT types required for opensolaris DLPI DL

[Sebastien Roy <Sebastien.Roy () Sun COM>]

On Fri, 2009-03-27 at 19:42 -0700, Guy Harris wrote:
> 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.

Right, that's essentially what I was trying to say as well.

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

Very true.  We could do that today.

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

That's also not a bad idea, and I didn't know that libpcap could do
that.

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

Okay, I'll talk to the OpenSolaris networking team about these options
and see where we should go with this.  It's very encouraging to see this
discussion, thanks!

-Seb


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