From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 6 16:38:13 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51FAA1065674; Mon, 6 Feb 2012 16:38:13 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id A604F8FC17; Mon, 6 Feb 2012 16:38:12 +0000 (UTC) Received: by lagz14 with SMTP id z14so4336251lag.13 for ; Mon, 06 Feb 2012 08:38:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.112.132 with SMTP id iq4mr9786953lab.28.1328546291290; Mon, 06 Feb 2012 08:38:11 -0800 (PST) Received: by 10.152.22.231 with HTTP; Mon, 6 Feb 2012 08:38:11 -0800 (PST) X-Originating-IP: [79.140.39.245] In-Reply-To: References: Date: Mon, 6 Feb 2012 17:38:11 +0100 Message-ID: From: Bernhard Schmidt To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org Subject: Re: [net80211] support vendor bitmap entries; teach if_ath to export PHY error code in error frames X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 16:38:13 -0000 On Sat, Feb 4, 2012 at 05:26, Adrian Chadd 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