Re: Extra DLT types required for opensolaris DLPI DL

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

On 27/03/09 05:03 PM, Guy Harris wrote:
> On Mar 27, 2009, at 1:45 PM, Darren Reed wrote:
> > On 27/03/09 11:27 AM, Guy Harris wrote:
> > > On Mar 27, 2009, at 10:58 AM, Darren Reed wrote:
> > > > Seriously, for my purposes, it is "Cisco HDLC".
> > >
> > > So it should be mapped to DLT_C_HDLC.
> > >
> > > > For the purposes of my table, I'd like to map the mediums that have 
> > > > passed (or are passing) from active use to "unsupported" and call 
> > > > it DLT_UNSUP (0xffffffff). On one level this is strange, because it 
> > > > isn't a DLT type, but it is a useful programming tool.
> > >
> > > So what's the table being used for?  libpcap has a switch statement 
> > > (in the top of the tree, it's in pcap_process_mactype() in 
> > > dlpisubs.c), as it needs to know more than just the DLT_ value for 
> > > particular link-layer types (and it maps DL_TPR to DLT_IEEE802).
> >
> > The devices in Solaris all use the DLPI types from <sys/dlpi.h>.
> >
> > I'm working on providing a native BPF for Solaris and I need to 
> > translate those DL_ types to DLT_ things.
>
> "BPF" can refer to two different things - the low-level packet 
> capture/transmit mechanism accessed by opening a BPF device and 
> reading from, writing to, and doing ioctls on, and the filter language 
> (and engines) that are used in systems with BPF, as well as in Linux, 
> WinPcap, and some other places (I think FreeBSD has a BPF netgraph node).
>
> I presume you're referring to the former, as the latter - a bpfmod 
> streams module as an alternative to pfmod - wouldn't require 
> translating DL_ types to DLT_ types (the filter itself knows nothing 
> about link-layer header types; the filter compiler in libpcap does, 
> but libpcap can and does already map DL_ types to DLT_ types).
>
> (If so, you will have a single cloning /dev/bpf device, rather than 
> the old "keep trying /dev/bpfN devices until you don't get EBUSY" 
> hack, right?)

Solaris doesn't support cloning for character devices (at present), so 
I'm forced to do /dev/bpfN.
There will be no STREAMS involved in this, it'll plug in directly to the 
mac layer.
The eventual goal is to support mmap and BPF JIT compiling.


> > While I'm here, additionally I'm looking at making PF_PACKET work and 
> > using pcap-linux.c as a guide, it isn't clear what or where a 
> > relevant header file should be called (yay linux mess!) Any thoughts 
> > on what you see making the most sense there?
>
> The packet(7) man page:
>
>     http://linux.die.net/man/7/packet
>
> says the header file for PF_PACKET sockets is <netpacket/packet.h>

I'll have to look at this man page...


> > Yes, thanks. It's 32bits.
> > zoneid_t is an "id_t", which is an int on LP64 and long otherwise, 
> > according to my <sys/types.h>.
>
> So that'd be
>
> version (16 bits: 1)
> protocol family (16 bits: AF_INET, AF_INET6)
> capture point (32bits enum: local, in, out)
> interface index (32bits)
> group interface index (32bits)
> source zone (32 bits)
> destination zone (32 bits)
>
> (and, obviously, Solaris AF_ values; everybody probably got their 
> AF_INET from 4.2BSD, so they're all the same, but just about everybody 
> seems to have their own unique value for AF_INET6).
>
> If you've settled on that, I'll assign DLT_LOOP_SOLARIS.

It looks good to me.  If we decide to change it or throw it out, I'll 
let you know.

Cheers,
Darren

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