Re: Vendor extensions on radiotap for Atheros

Johannes Berg <[email protected]> Wed, 26 Aug 2009 22:00:31 +0200

Newsgroups	org.netbsd.radiotap
Message-ID	<[email protected]>

On Wed, 2009-08-26 at 14:51 -0500, David Young wrote:

> I should underscore that for backwards compatibility, an implementation
> should not interpret bit 29 or bit 30 as an implicit extension of the
> presence-bitmap, but you still have to use bit 31, the presence-bitmap
> extension bit, to extend the bitmap.

Indeed. The text there says:

        Before it resumes interpretation of presence bits in the
        following 32-bit presence words, if any, the interpreter shall
        reset its presence-bitmap index to 0, and change to the vendor
        namespace specified by the OUI and selector. 

or

        Upon interpreting this field, the interpreter shall reset its
        presence-bitmap index to 0 and its namespace to the default
        radiotap namespace, and change to the default radiotap
        namespace, before it interprets subsequent presence-bitmap
        words. 

but of course that's useless unless you also used bit 31 to indicate
that there actually _are_ follow-up bitmaps.

But I think we should follow the standard practise of having a generator
and a parser for this. Then again, a generator may be hard, so maybe
just a parser in wireshark or so. Showing multiple trees if there are
multiple standard namespaces, and skipping over vendor namespaces while
showing the vendor would be nice. Bonus points for making it easily
extensible so vendors who care to publish what they do in their
namespace can extend wireshark easily.

Or we could make a patch for linux to generate multiple namespaces for
multi-rate retries -- we have the info just don't publish it right now
(we only show the first rate).

johannes

signature.asc (application/pgp-signature, 801 B)