On Wed, 19 Sep 2001, Andrew Brown wrote:

> >> I'd like to have a device (/dev/wi0 or something) that can be used as
> >> a method to pass data into and out of the kernel.  I'd use this as a
> >> way to pass along packets that perhaps I don't want to send to the
> >> IP stack (management, encrypted or undecryptable frames, etc) as
> >> well as a general purpose async notification pipe for monitoring
> >> AP associations, signal strengths, etc.
> >
> >I've heard BSD/OS uses BPF to capture 802.11 packets, which is basically
> >the right way, IMHO.
>
> we currently have the bpf tap attached after the pseudo ethernet
> header is constructed, so 802.11 packets end up looking like regular
> ethernet packets.  would it be outlandish for me to suggest an ioctl
> to frob this?

As I mentioned, I was looking into this too, but Michael is farther along.
:-)

The concensus I'd heard when I asked the right way to do this was that
we'd need to teach bpf about 802.11 frames, i.e. DLT_IEEE80211. I'm not
sure how a bpf user would say it wanted to get one or the other.

> >But it is hard to send 802.11 frame via BPF because it is not clear
> >what field should be filled by the driver.  Obviously, some information
> >such as seqence control should be consistent with the normal IP packets.
> >And there may be a discussion who should take care of encryption.
> >Some device cannot skip hardware encryption/decryption engine.
>
> there's an ioctl (SIOCSWAVELAN, i think) that allows you to construct
> arbitrary 802.11 frames.  at least...that's what it looked like to me.
>
> >And if we change the bpf type from DLT_EN10MB, the application like
> >dhclient(8) must be updated.  So I'm thinking the way to creating switch
> >controlled by ioctl for bpf device.
>
> yeah.  me too.  :)

That would work.

Take care,

Bill