Subject: Re: adding an 802.11 data link type
To: None <email@example.com>
From: Atsushi Onoe <firstname.lastname@example.org>
Date: 08/05/2002 14:54:06
> 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.
> 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.
> 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
> BIOCSDLT -- change the DLT for the bpf socket to one of the supported
> 4) a driver will only build frames that listeners want
> If this is not substantially how people desire for the 802.11 DLT to work,
> let me know.
> If somebody has already begun to program this feature, stop me.
I'll search the code once I've implemented from my backups.