> While I think it'd be good to get at those, if they aren't in the 802.11
> header, I don't think they should be sent out bpf.

The rate parameter might be useful for sending packet.
And how to fill sequence control field should be discussed.

> I can see three modes of interest. Things listening to 802.3 frames (both
> bpf listeners and the kernel's input path), things listening to
> 802.11-only frames (management frames, things which don't just turn into
> 802.3 frames), and things listening for 802.11 versions of 802.3 frames.

The second things can be filtered by bpf if 802.11 modes turned on,
by testing
	((i_ic[0] & IEEE80211_FC0_TYPE_MASK) != IEEE80211_FC0_TYPE_DATA)

> So where this is going is that I think we should always hand an 802.3
> frame off to bpf (bpf would know to not hand 802.3 frames to 802.11
> listeners and vis versa). But we should only bother with 802.11 frames
> when someone requests them.
> 
> Note this involves changing bpf a bit in that right now I think it only
> deals with one type of packet per interface.

How about adding DLT_ argument to bpf_mtap()?
Or creating a new interface,
	void bpf_mtap_type(caddr_t, struct mbuf *, int);

Atsushi Onoe