> 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
be better.

>       BIOCSDLT  -- change the DLT for the bpf socket to one of the supported
>                    types

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

Atsushi Onoe