Subject: Re: adding an 802.11 data link type
To: Atsushi Onoe <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
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.