#
237214 |
|
18-Jun-2012 |
adrian |
Extend the radiotap code to be aware of the size of any extra vendor bitmaps that may occur.
The way this works is:
* the beginning of the radiotap frame has a 32 bit "radiotap" namespace bitmap; * if the vendor bitmap bit is set, then the next bitmap will be interpreted as a vendor bitmap; * this can keep going on and on (ie, more vendor and radiotap namespace bitmaps can be added) until the last bitmap with no "more bitmaps" set.
Now, the radiotap code gets its grubby fingers into the supplied radiotap rx/tx buffer and replaces the channel configuration for each frame. I don't know why it's not up to the drivers themselves to do this, but I digress. So, if a vendor bitmap (or two, etc) exists, the offset calculations will be all completely wrong.
This particular patch introduces ieee80211_radiotap_attachv(), which includes the number of vendor bitmaps (well, any other bitmaps, vendor or otherwise) between the end of the bitmap/header and the start of the actual radiotap field entries. This makes the radiotap calculations "right", so it correctly calculates where to overwrite the channel configuration.
The long term fix is to go through and make each driver update the channel configuration, as some of the fields are already being updated.
That, however, is a longer term fix that will need each driver fixed.
I leave that as an exercise to someone in the future.
|
#
192468 |
|
20-May-2009 |
sam |
Overhaul monitor mode handling: o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO and remove explicit bpf support from wireless drivers; drivers now use ieee80211_radiotap_attach to setup shared data structures that hold the radiotap header for each packet tx/rx o remove rx timestamp from the rx path; it was used only by the tdma support for debugging and was mostly useless due to it being 32-bits and mostly unavailable o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and per-com state when there are active taps o track the number of monitor mode vaps o use bpf tap and monitor mode vap state to decide when to collect radiotap state and dispatch frames; drivers no longer explicitly directly check bpf state or use bpf calls to tap frames o handle radiotap state updates on channel change in net80211; drivers should not do this (unless they bypass net80211 which is almost always a mistake) o update various drivers to be more consistent/correct in handling radiotap o update ral to include TSF in radiotap'd frames o add promisc mode callback to wi
Reviewed by: cbzimmer, rpaulo, thompsa
|