Date: Mon, 6 Feb 2012 17:38:11 +0100 From: Bernhard Schmidt <bschmidt@techwires.net> To: Adrian Chadd <adrian@freebsd.org> 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: <CAAgh0_aAijDoguQCJO8jR=cZ5LrZGLfxpGruZWGsjGf987-zOw@mail.gmail.com> In-Reply-To: <CAJ-VmonSrcSQmZeENgH1fagnn6DOMhX6rC-n9=dOtypTabcSLg@mail.gmail.com> References: <CAJ-VmonSrcSQmZeENgH1fagnn6DOMhX6rC-n9=dOtypTabcSLg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 4, 2012 at 05:26, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi,
>
> As part of my radar project, I'm going to try and teach the BSD/Linux
> ath driver and radiotap API about vendor extensions and implement a
> (reasonably) well documented way to expose what I need.
>
> The driver already exports the whole PHY error frame payload via
> radiotap and you can select which PHY error types are passed up by
> setting bits in the dev.ath.X.monpass sysctl. The trouble is the PHY
> error code isn't exposed so it currently isn't possible to know
> whether its a data or a PHY error frame.
>
> This patch is a WIP and implements what I need. In short:
>
> * The net80211 radiotap code doesn't know about vendor extension
> bitmap(s), so there's currently no way to take those into account when
> calculating the channel state offset in the header. Since the radiotap
> code directly writes into that (rather than have the driver do it per
> frame), adding any vendor bitmaps does mess things up quite a bit.
>
> * define a vendor attribute in if_athioctl.h - this should move to
> ieee80211_radiotap.h at some point.
>
> * Add fields to the ath RX radiotap struct, which includes the vendor
> bitmap, vendor attribute and the vendor payload.
>
> * Add a vendor payload, which includes the Atheros OUI and the RX
> status + PHY error code.
>
> With this, userland tools can be built to read the radar and spectral
> scan PHY error frames in userland. It makes prototyping code much,
> much easier.
>
> What I'm going to do to this:
>
> * Move the vendor attribute definition into ieee80211_radiotap.h;
> * Finalise on the Atheros vendor attribute layout. It doesn't match
> what is used in the reference driver but I'll use different vendor
> bitmap/namespace bytes, so things won't clash.
> * Document the new ieee80211_radiotap_attachv() and why it exists.
>
> I'd appreciate some feedback.
>
> Thanks!
> static void
> +ath_rx_tap_vendor(struct ifnet *ifp, struct mbuf *m,
> + const struct ath_rx_status *rs, u_int64_t tsf, int16_t nf)
> +{
> + struct ath_softc *sc = ifp->if_softc;
> +
> + /* Fill in the extension bitmap */
> + sc->sc_rx_th.wr_ext_bitmap = htole32(1 << ATH_RADIOTAP_VENDOR_HEADER);
> +
> + /* Fill in the vendor header */
> + sc->sc_rx_th.wr_vh.oui[0] = 0x7f;
> + sc->sc_rx_th.wr_vh.oui[1] = 0x03;
> + sc->sc_rx_th.wr_vh.oui[2] = 0x00;
> +
> + /* 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
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).
--
Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAAgh0_aAijDoguQCJO8jR=cZ5LrZGLfxpGruZWGsjGf987-zOw>