]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Extend the radiotap code to be aware of the size of any extra vendor
authoradrian <adrian@FreeBSD.org>
Mon, 18 Jun 2012 02:08:04 +0000 (02:08 +0000)
committeradrian <adrian@FreeBSD.org>
Mon, 18 Jun 2012 02:08:04 +0000 (02:08 +0000)
commit5958fc908c1cd2b73e214062694a231a7d8c6f53
tree5173b3fd4d0290a622c89c4ef29de47ce8f8bc96
parent0f64633c511f78f08d6c1a1e42f8ac3c9b994b44
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.
sys/net80211/ieee80211_radiotap.c
sys/net80211/ieee80211_var.h