From owner-freebsd-wireless@FreeBSD.ORG Mon Feb 6 19:18:04 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 114E11065674 for ; Mon, 6 Feb 2012 19:18:04 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4498FC18 for ; Mon, 6 Feb 2012 19:18:03 +0000 (UTC) Received: by werm13 with SMTP id m13so7246206wer.13 for ; Mon, 06 Feb 2012 11:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lC4ZbjJPi9OYwT9XoSEpxLCMF5rNLRhYqHXUlR32LMA=; b=elKWNoAefwSlfus/Z0sZPhcMQOKatF80P5mqYEPywg4zOuKQDV85gcrOzVQizDhhoW pwwLZZb2L/7fqsB8KKF7HCCH/gL5M0iF/2X7hsi02CcdakacMTpHp5MmsidOJYU2nmLM bikDHAWgm3/xmo6Fgw8W8Z8Z950kIEt6aVpmA= MIME-Version: 1.0 Received: by 10.216.137.210 with SMTP id y60mr3845749wei.14.1328555882592; Mon, 06 Feb 2012 11:18:02 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.175.136 with HTTP; Mon, 6 Feb 2012 11:18:02 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Feb 2012 11:18:02 -0800 X-Google-Sender-Auth: 5B8ZLc7MMEr8lbH5S1DTg54DOcU Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:18:04 -0000 On 6 February 2012 08:38, Bernhard Schmidt 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