>> 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.
>
>One thing to note is that the driver may have some custom bits to
>inject before the 802.11 header, such as received signal strength,
>data rate, etc.  I'd like to retain that if possible.

of course.

>I now have two modes the _driver_ can be put in -- one is standard
>mode where 802.11 frames are not returned, but translated into 802.3.
>
>The other mode is a raw mode where the wi_frame portion is returned,
>followed by raw packet data.  This is a special "monitor" mode, and
>is only returned after an ioctl tells the prism2 chip to return all
>seen data in promiscious mode.  The obvious reason for that is to
>experiment with airsnort (which I have cracking my home network's
>keys now)

almost but not exactly what i was thinking.  i imagine you're playing
catch up with email...how possible would it be to have two places in
the wi driver where it passes packets up to bpf, and have a bpf ioctl
that selects between the two (with ethernet encapsulation being the
default)?

>Changing the BPF type will break dhcp, I believe, unless the default
>mode is normal ethernet.  But then, do we add 802.11 -> 802.3
>translation in the pcap library?

if dhcp never issues the ioctl to select 802.11 encapsulation, it
ought to win just fine.

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