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

off the top of my head, i'd suggest that the default action be to
receive ethernet frames from the bpf, but provide an ioctl to switch
to the 802.11 format if you want it.  that ought to provide for total
backwards compatibility very easily.  imagine, if you will, a
companion ioctl to BIOCGDLT called BIOCSDLT that can set a bpf
attached to an 802.11 interface into DLT_IEEE80211?

the more fun project with be the one that allows you to switch from
regular packets to raw, unencrypted, 802.11 frames (with the caveat,
of course, that while you are doing this you can't use the interface
for anything else).

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

default to DLT_EN10MB, but provide a way to switch to DLT_IEEE80211.  :)

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."