Date: Mon, 6 Feb 2012 20:59:16 +0100 From: Bernhard Schmidt <bschmidt@freebsd.org> 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: <201202062059.16816.bschmidt@freebsd.org> In-Reply-To: <CAJ-Vmon%2BpQ9U7-YEQ1pYVbHM=5D=cp-z6eoPGJhV_GU3r7hy8A@mail.gmail.com> References: <CAJ-VmonSrcSQmZeENgH1fagnn6DOMhX6rC-n9=dOtypTabcSLg@mail.gmail.com> <CAAgh0_aAijDoguQCJO8jR=cZ5LrZGLfxpGruZWGsjGf987-zOw@mail.gmail.com> <CAJ-Vmon%2BpQ9U7-YEQ1pYVbHM=5D=cp-z6eoPGJhV_GU3r7hy8A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 06 February 2012 20:18:02 Adrian Chadd wrote: > On 6 February 2012 08:38, Bernhard Schmidt <bschmidt@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. You're right, found a sample capture which confirmed that. > > 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. Given that the calculation of the offsets is totally unrelated to the length of the actually vendor specific data, couldn't you just add the length of the additional ext field + padding based on the presents of VENDOREXT? -- Bernhard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202062059.16816.bschmidt>