Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Feb 2012 11:18:02 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Bernhard Schmidt <bschmidt@techwires.net>
Cc:        freebsd-wireless@freebsd.org
Subject:   Re: [net80211] support vendor bitmap entries; teach if_ath to export PHY error code in error frames
Message-ID:  <CAJ-Vmon%2BpQ9U7-YEQ1pYVbHM=5D=cp-z6eoPGJhV_GU3r7hy8A@mail.gmail.com>
In-Reply-To: <CAAgh0_aAijDoguQCJO8jR=cZ5LrZGLfxpGruZWGsjGf987-zOw@mail.gmail.com>
References:  <CAJ-VmonSrcSQmZeENgH1fagnn6DOMhX6rC-n9=dOtypTabcSLg@mail.gmail.com> <CAAgh0_aAijDoguQCJO8jR=cZ5LrZGLfxpGruZWGsjGf987-zOw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 6 February 2012 08:38, Bernhard Schmidt <bschmidt@techwires.net> wrote:

>> + =A0 =A0 /* XXX what should this be? */
>> + =A0 =A0 sc->sc_rx_th.wr_vh.sub_namespace =3D 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon%2BpQ9U7-YEQ1pYVbHM=5D=cp-z6eoPGJhV_GU3r7hy8A>