From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 6 19:59:11 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 56C8C1065672; Mon, 6 Feb 2012 19:59:11 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B1BD28FC18; Mon, 6 Feb 2012 19:59:10 +0000 (UTC) Received: by bkbzx1 with SMTP id zx1so6873793bkb.13 for ; Mon, 06 Feb 2012 11:59:09 -0800 (PST) Received: by 10.204.9.198 with SMTP id m6mr8939830bkm.74.1328558349461; Mon, 06 Feb 2012 11:59:09 -0800 (PST) Received: from amy.lab.techwires.net (dslb-088-067-204-237.pools.arcor-ip.net. [88.67.204.237]) by mx.google.com with ESMTPS id x20sm48533949bka.9.2012.02.06.11.59.06 (version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 11:59:08 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Mon, 6 Feb 2012 20:59:16 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-PRERELEASE; KDE/4.7.3; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202062059.16816.bschmidt@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 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 19:59:11 -0000 On Monday 06 February 2012 20:18:02 Adrian Chadd wrote: > On 6 February 2012 08:38, Bernhard Schmidt 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