Sebastien Roy wrote:
> On Wed, 2009-08-12 at 21:40 -0700, Darren Reed wrote:
>> Ah, I see what you're driving at.
>>
>> So I suppose the task then is to implement both DLT_NULL and
>> DLT_IPNET for lo0 as opposed to just DLT_IPNET.
>>
>> I hadn't considered that...
>
> Or DLT_RAW for /dev/lo0 (I think this implies that packets begin with an
> IP header).  /dev/lo0 is simply there for compatibility with OSs that
> have a similar device, and those OSs certainly don't use the ipnet
> header on /dev/lo0.  Perhaps that would be acceptable.
>
> The BPF functionality that switches the device used based on DLT value
> has its drawbacks, and one of them is clear here.  For one, selecting
> the "ipnet" lo0 (/dev/ipnet/lo0) with DLT_IPNET also implies that the
> packets received will have an ipnet header.  Using DLT_RAW (or DLT_NULL)
> to select the /dev/lo0 semantics also implies that there isn't an ipnet
> header, which is unfortunate.

Well, it is up to us to decide what the behaviour should be.

My take on this is that there is no point in us having
another DLT for /dev/lo0. The reason that other OS's use
DLT_NULL is that the only useful information that needs
to be prepended is the address family of the packet.


Maybe a different way to look at this is if OpenSolaris
did not have zones or IPNET then the choice would be
whether or not to provide a DLT_NULL packet type for
packets captured from lo0 (assuming that the choice was
made to prsent lo0 packets through BPF as well as normal
packets from below IP.)

I think that there is a reasonably good chance that this
decision would be made. Thus if zones and later ipnet was
delivered on top of that, we would end up with DLT_NULL
and DLT_IPNET for ipnet on lo0.

> Perhaps another way to handle this would be to have a Solaris "loopback"
> DLT type that both implies /dev/lo0 _and_ ipnet headers, but I'm not
> sure that's really necessary given the nature of /dev/lo0.

Right.

Darren


Reply via email to