Vendor extensions on radiotap for Atheros

Vendor extensions on radiotap for Atheros

[Luis R. Rodriguez]

[ resending to the right new e-mail distribution list now ]

Atheros would like to start using Radiotap vendor extensions [1]. Do
we just start using our OUI for this, extend the extension info on the
wiki and perhaps contribute parsing of it to existing parsers?

Is that the procedure?

 Luis

[1] http://www.radiotap.org/Discussion/Vendor-Extensions

Re: Vendor extensions on radiotap for Atheros

[David Young]

On Wed, Aug 26, 2009 at 10:52:30AM -0700, Luis R. Rodriguez wrote:
> [ resending to the right new e-mail distribution list now ]
> 
> Atheros would like to start using Radiotap vendor extensions [1]. Do
> we just start using our OUI for this, extend the extension info on the
> wiki and perhaps contribute parsing of it to existing parsers?
> 
> Is that the procedure?

Yes, except we haven't adopted vendor extensions as a standard.  Step 1:
propose (and adopt) vendor extensions as a standard.  Step 2: the rest.

> [1] http://www.radiotap.org/Discussion/Vendor-Extensions

I think it is a good description, is it understood by everyone?

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.

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933

Re: Vendor extensions on radiotap for Atheros

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]