Subject: Re: adding an 802.11 data link type
To: Atsushi Onoe <onoe@sm.sony.co.jp>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-net
Date: 08/05/2002 14:51:32
On Mon, 5 Aug 2002, Atsushi Onoe wrote:

> > I would like to add an 802.11 DLT to NetBSD so that I can observe 802.11
> > mgmt/ctl frames through bpf.
>
> Sorry for lazy activities on this topic...
>
> > In the discussion on the 802.11 DLT in May, it appears that a rough consensus
> > was reached, namely that
> >
> >  0) DLTs DLT_802_11, DLT_PRISM_802_11, DLT_AIRONET_802_11 are desirable
> >     in addition to DLT_EN10MB.
>
> I think it would be better if we define DLT_DRVSPEC for all driver specific
> raw format, since I don't want to implement DLT_AIRONET_ for 'wi' driver.

I think all the different specific types would be better. Note though that
the wi driver wouldn't need to do DLT_AIRONET_.

> >  1) A driver supporting more than one DLT will call bpf with a new
> >     procedure, bpfattach_multidlt, passing bpfattach_multidlt a mask
> >     describing the DLTs the driver supports.
>
> Since the number of supported DLTs for a driver would be limited,
> multiple calls to bpfattach_dlt() may be accepted.
> This would help to implement streight forward implementation which splits
> bpf_if for each DLT.

But do we want multiple bpf_if's? My original idea was there would be one
bpf, just it could hand back different packet types.

> >  2) 802.11 interfaces will default to handing up 802.3 frames to bpf,
> >     so that dhclient, tcpdump, etc. do not break.
>
> >  3) Two new ioctl's list/choose the DLT used by bpf:
> >
> >       BIOCGDLTS -- returns a bit vector. "Lit" bits indicate supported DLTs.
> >                    For example, on an 802.11 interface, the DLT_EN10MB'th
> >                    bit and the DLT_802_11'th bit will be set.
>
> It seems that the range of the value for DLT is not defined. BIOCGDLT
> just uses u_int to pass it.  So returning array of supported DLTs would
> be better.

Right.

Take care,

Bill