Re: Extra DLT types required for opensolaris DLPI DL

[Guy Harris <guy () alum mit edu>]

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

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

> If you're wondering "why both", imho, one is designed to program  
> with and one is designed for packet capture.

BPF was designed with more of an eye towards packet capture, and less  
with an eye towards implementing link-layer protocols in userland,  
than were PF_PACKET sockets.  Both are, and can be, used for both  
purposes, however.

Arguably, a library for writing link-layer protocols in userland,  
separate from libpcap, would be useful.  For example:

	on a number of platforms, the former library would bind to the low- 
level networking stack with a particular SAP rather than  
"promiscuously" for all SAPs (I think that would be the case on Linux,  
Windows with the WinPcap driver and packet.dll library, and systems  
with DLPI - and, at least on HP-UX, where I think you can have only  
one DLPI stream in "SAP promiscuous" mode, it'd work better that way);

	for packet capturing, you usually want buffering done in the kernel,  
so that you get multiple packets per read, while, when implementing a  
link-layer protocol, you usually want packets delivered as soon as  
they arrive;

	for some link-layer protocols, you might want the details of  
particular link layers hidden from your implementation, e.g. Ethernet  
types vs. 802.2+SNAP headers.

I really wish I had time to implement that right now.

> 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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.