[net80211] support vendor bitmap entries; teach if_ath to export PHY error code in error frames

Adrian Chadd adrian at freebsd.org
Mon Feb 6 19:18:04 UTC 2012


On 6 February 2012 08:38, Bernhard Schmidt <bschmidt at techwires.net> wrote:

>> +     /* XXX what should this be? */
>> +     sc->sc_rx_th.wr_vh.sub_namespace = 0;
>
> Are you sure about that? If I get the "Vendor Namespace" description
> on radiotap.org right the wr_vh.sub_namespace field should actually
> contain what you moved into wr_ext_bitmap. Otherwise

Nono - the sub_namespace defines how to interpret the 29 bit bitmask
(with bits 29, 30, 31 being always defined as vendor/radiotap/ext
bits, regardless of which namespace you're in.)
Ie:

* in radiotap mode, the namespace is "radiotap"
* when you set the vendor bit in the bitmask (and ext), the next
bitmap is a vendor bitmask in the namespace defined by
"sub_namespace";
* then you set the radiotap (and ext) bit in the vendor bitmask, the
next bitmask is in the radiotap namespace again.

> ATH_RADIOTAP_VENDOR_HEADER must be defined by radiotap and have it's
> own data. If I'm right we don't need wr_ext_bitmap at all and
> therefore neither ieee80211_radiotap_attachv() and the different
> offset handling, only setting IEEE80211_RADIOTAP_VENDOREXT is required
> (not IEEE80211_RADIOTAP_EXT).

I haven't checked to see whether I can get away with just setting
VENDOREXT but not EXT.

I've checked this with Johannes and it looks right. But the lack of
documentation and the existance of a 6 bit vendor header that
precludes the vendor payload being in any way "naturally aligned"
without hacks is just .. grr.

I'll post an updated patch in an hour or two. I have this now working
complete with a userland radar phy frame parsing app. I'll go and post
all of this soon.



Adrian


More information about the freebsd-wireless mailing list