> Is anyone looking at adding 802.11 support to NetBSD's libpcap,
> and appropriate stuff to the drivers so we could do low-level
> sniffing of wireless networks?

Once I've tried but not yet done.  There are several issues from my
memory:

1. How to select raw 802.11 frame or ethernet compatible mode?

A possible solution is switch to using 802.11 frame without emulating
ethernet.  But it requires all bpf applications such as dhcp to handle
802.11 frame.  In addition to this incompatibility, filling 802.11 header
to send frame is difficult for application level.  For example, some
firmware encrypt WEP when WEP bit is on, which is hard to be known to
applications.

Another solution is change the mode of interface (at least bpf
interface), but it is problematic if dhclient wants to renew the lease
during tcpdump makes the mode of bpf interface to raw 802.11 frame.

The code I've once implemented is to select the mode of bpf device
by introducing BIOCSDLT ioctl, which only change the mode of the
bpf device and doesn't affect other bpf listener of the corresponding
interface.  It looks work fine, but cannot help tcpdump.  Tcpdump
doesn't care about file descriptor opened by libpcap.  And if I
change the libpcap to enable raw 802.11 mode automatically, all
applications using libpcap are affected.

The only way I can imagine which doesn't require any API change is
preparing pseudo interface like "wi0/802.11", e.g. tcpdump -i wi0/802.11.
But I feel it is too ugly to implement...

2. The bpf packet format assumed by tcpdump is not so good.

The current implmentation of tcpdump assumes 802.11 header immediately
followed by SNAP header and data (e.g. IP) packet.  But it confuses
libpcap to filter ip/tcp/... because 802.11 header is defined as
variable length.  And there are no room to deliver useful information
such as RSSI or encoded rate, though it doesn't belong to actual header.

3. How to handle WEP frame?  deliver undecrypted? or decrypted?

Most of the firmware automatically decrypt if WEP ICV matches.

4. How to select possible monitor mode?

There can be various receiving mode.
	By frame type:
		- data frame only
		- data frame and management frame
		- all frames including control frame (e.g. ACK)
	By address:
		- destined to the node only (non-promiscuous)
		- all destination within connected bss
		- any packet in specified channel
Also note some of the firmware (such as aironet) need to stop transmitter
to enter some of the monitor modes.  So normal TCP/IP communications
must be disabled to monitor frames.


I could implement monitor mode once these issues are solved.
(...and if I have a hacking time)

Atsushi Onoe