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