radiotap feature discovery

radiotap feature discovery

[Johannes Berg]

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

Hi!

With all these injection things, we'll invariably find devices that do
not support some of them, e.g. will not support not setting the sequence
number because the hardware always assigns them.

Thus, I think we need a way to do feature discovery. This isn't relevant
for RX -- there the driver just provides what it has -- but is for TX
where tools would like to know what they can do.

One way I could think of would be to define a whole bunch of flags for
the various injection features, and export those somehow. Not sure I
like this, since it means we need to keep track of yet another bitmap.

The other way I could imagine would be to export, in a yet to be defined
way, a radiotap header that lists the capabilities. For example, upon
feature query you'd return a header like this:

	0x00, 0x00,		// <-- radiotap version
	0x0b, 0x00,		// <- radiotap header length
	0x04, 0x84, 0x00, 0x00,	// <-- bitmap
	0x00,			// <-- rate
	0x00,			// <-- tx power
	0x08, 0x00		// <-- tx flags

This would indicate support for controlling
 * rate
 * tx power
 * tx flags - only no-ACK

How to export this information is to be determined and would most likely
be platform dependent though.

Thoughts?

johannes

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

Re: radiotap feature discovery

[Johannes Berg]

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

On Thu, 2009-04-16 at 18:02 +0200, Johannes Berg wrote:

> The other way I could imagine would be to export, in a yet to be defined
> way, a radiotap header that lists the capabilities. For example, upon
> feature query you'd return a header like this:
> 
> 	0x00, 0x00,		// <-- radiotap version
> 	0x0b, 0x00,		// <- radiotap header length
> 	0x04, 0x84, 0x00, 0x00,	// <-- bitmap
> 	0x00,			// <-- rate
> 	0x00,			// <-- tx power
> 	0x08, 0x00		// <-- tx flags

Oops, that header length was broken, should be 0x0c, 0x00

johannes

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

Re: radiotap feature discovery

[David Young]

On Thu, Apr 16, 2009 at 06:02:37PM +0200, Johannes Berg wrote:
> Hi!
> 
> With all these injection things, we'll invariably find devices that do
> not support some of them, e.g. will not support not setting the sequence
> number because the hardware always assigns them.
> 
> Thus, I think we need a way to do feature discovery. This isn't relevant
> for RX -- there the driver just provides what it has -- but is for TX
> where tools would like to know what they can do.
> 
> One way I could think of would be to define a whole bunch of flags for
> the various injection features, and export those somehow. Not sure I
> like this, since it means we need to keep track of yet another bitmap.
> 
> The other way I could imagine would be to export, in a yet to be defined
> way, a radiotap header that lists the capabilities. For example, upon
> feature query you'd return a header like this:
> 
> 	0x00, 0x00,		// <-- radiotap version
> 	0x0b, 0x00,		// <- radiotap header length
> 	0x04, 0x84, 0x00, 0x00,	// <-- bitmap
> 	0x00,			// <-- rate
> 	0x00,			// <-- tx power
> 	0x08, 0x00		// <-- tx flags
> 
> This would indicate support for controlling
>  * rate
>  * tx power
>  * tx flags - only no-ACK
> 
> How to export this information is to be determined and would most likely
> be platform dependent though.

Some standardization may be possible.  For example, Linux, *BSD, et
cetera, may be able to share a getsockopt(2) interface for querying
the capabilities on a socket.  Platforms with BPF could share an
ioctl(2) interface for the same.

> Thoughts?

Suppose that we let the OS pass back one or more "capability headers."
Each capability header consists of two radiotap headers.  The first
header contains supported Tx parameters.  The second header must be as
long as the first, and it is a bitmap that tells which bits are variable
(0) and which are fixed (1).  In your example, the first header

> 	0x00, 0x00,		// <-- radiotap version
> 	0x0b, 0x00,		// <- radiotap header length
> 	0x04, 0x84, 0x00, 0x00,	// <-- bitmap
> 	0x00,			// <-- rate
> 	0x00,			// <-- tx power
> 	0x08, 0x00		// <-- tx flags

may be followed by the bitmap

> 	0xff, 0xff,		// <-- radiotap version
> 	0xf0, 0xff,		// <- radiotap header length
> 	0xfb, 0x7b, 0xff, 0xff,	// <-- bitmap
> 	0x00,			// <-- rate
> 	0x00,			// <-- tx power
> 	0xf7, 0xff		// <-- tx flags

meaning that only radiotap version 0 is supported, the header length is
somewhat variable, only rate, tx power and flags may be set, and only
the no-ACK Tx flag is allowed.

Dave

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

Re: radiotap feature discovery

[Johannes Berg]

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


> > The other way I could imagine would be to export, in a yet to be defined
> > way, a radiotap header that lists the capabilities. For example, upon
> > feature query you'd return a header like this:
> > 
> > 	0x00, 0x00,		// <-- radiotap version
> > 	0x0b, 0x00,		// <- radiotap header length
> > 	0x04, 0x84, 0x00, 0x00,	// <-- bitmap
> > 	0x00,			// <-- rate
> > 	0x00,			// <-- tx power
> > 	0x08, 0x00		// <-- tx flags
> > 
> > This would indicate support for controlling
> >  * rate
> >  * tx power
> >  * tx flags - only no-ACK
> > 
> > How to export this information is to be determined and would most likely
> > be platform dependent though.
> 
> Some standardization may be possible.  For example, Linux, *BSD, et
> cetera, may be able to share a getsockopt(2) interface for querying
> the capabilities on a socket.  Platforms with BPF could share an
> ioctl(2) interface for the same.

Indeed, that would be doable. Any suggestions?

> > Thoughts?
> 
> Suppose that we let the OS pass back one or more "capability headers."
> Each capability header consists of two radiotap headers.  The first
> header contains supported Tx parameters.  The second header must be as
> long as the first, and it is a bitmap that tells which bits are variable
> (0) and which are fixed (1).  In your example, the first header
> 
> > 	0x00, 0x00,		// <-- radiotap version
> > 	0x0b, 0x00,		// <- radiotap header length
> > 	0x04, 0x84, 0x00, 0x00,	// <-- bitmap
> > 	0x00,			// <-- rate
> > 	0x00,			// <-- tx power
> > 	0x08, 0x00		// <-- tx flags
> 
> may be followed by the bitmap
> 
> > 	0xff, 0xff,		// <-- radiotap version
> > 	0xf0, 0xff,		// <- radiotap header length
> > 	0xfb, 0x7b, 0xff, 0xff,	// <-- bitmap
> > 	0x00,			// <-- rate
> > 	0x00,			// <-- tx power
> > 	0xf7, 0xff		// <-- tx flags
> 
> meaning that only radiotap version 0 is supported, the header length is
> somewhat variable, only rate, tx power and flags may be set, and only
> the no-ACK Tx flag is allowed.

Hmm. That seems useful on first sight, but is it really? It seems to be
useful only for things like the tx flags.

Supporting multiple radiotap versions is still impossible, since the
bits would have entirely different meanings, or even the format changed,
otherwise we wouldn't have cycled the version number.

For the bitmap we already know - I don't think any reasonable
implementation would _require_ some field to be present.

For rate/txpower there may be limits you cannot express with this, but
must discover in some other way, or the implementation just clamps or
something.

So that leaves tx flags only, and could there really be flags that are
_required_ to be set or will be assumed to be set? I guess with the
'override default' thing I just asked for that might make sense...

johannes

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

Re: radiotap feature discovery

[David Young]

On Thu, Apr 16, 2009 at 07:30:02PM +0200, Johannes Berg wrote:
> 
> > > The other way I could imagine would be to export, in a yet to be defined
> > > way, a radiotap header that lists the capabilities. For example, upon
> > > feature query you'd return a header like this:
> > > 
> > > 	0x00, 0x00,		// <-- radiotap version
> > > 	0x0b, 0x00,		// <- radiotap header length
> > > 	0x04, 0x84, 0x00, 0x00,	// <-- bitmap
> > > 	0x00,			// <-- rate
> > > 	0x00,			// <-- tx power
> > > 	0x08, 0x00		// <-- tx flags
> > > 
> > > This would indicate support for controlling
> > >  * rate
> > >  * tx power
> > >  * tx flags - only no-ACK
> > > 
> > > How to export this information is to be determined and would most likely
> > > be platform dependent though.
> > 
> > Some standardization may be possible.  For example, Linux, *BSD, et
> > cetera, may be able to share a getsockopt(2) interface for querying
> > the capabilities on a socket.  Platforms with BPF could share an
> > ioctl(2) interface for the same.
> 
> Indeed, that would be doable. Any suggestions?
> 
> > > Thoughts?
> > 
> > Suppose that we let the OS pass back one or more "capability headers."
> > Each capability header consists of two radiotap headers.  The first
> > header contains supported Tx parameters.  The second header must be as
> > long as the first, and it is a bitmap that tells which bits are variable
> > (0) and which are fixed (1).  In your example, the first header
> > 
> > > 	0x00, 0x00,		// <-- radiotap version
> > > 	0x0b, 0x00,		// <- radiotap header length
> > > 	0x04, 0x84, 0x00, 0x00,	// <-- bitmap
> > > 	0x00,			// <-- rate
> > > 	0x00,			// <-- tx power
> > > 	0x08, 0x00		// <-- tx flags
> > 
> > may be followed by the bitmap
> > 
> > > 	0xff, 0xff,		// <-- radiotap version
> > > 	0xf0, 0xff,		// <- radiotap header length
> > > 	0xfb, 0x7b, 0xff, 0xff,	// <-- bitmap
> > > 	0x00,			// <-- rate
> > > 	0x00,			// <-- tx power
> > > 	0xf7, 0xff		// <-- tx flags
> > 
> > meaning that only radiotap version 0 is supported, the header length is
> > somewhat variable, only rate, tx power and flags may be set, and only
> > the no-ACK Tx flag is allowed.
> 
> Hmm. That seems useful on first sight, but is it really? It seems to be
> useful only for things like the tx flags.

I think that the usefulness comes down to either the interpretation
(bad) or the rigor of the specification.

> Supporting multiple radiotap versions is still impossible, since the
> bits would have entirely different meanings, or even the format changed,
> otherwise we wouldn't have cycled the version number.

Sure.

> For the bitmap we already know - I don't think any reasonable
> implementation would _require_ some field to be present.

Neither do I.  I marked the bits in the presence bitmap 
as variable instead of fixed for that reason.  Do you think it
is too confusing for the fields to still be present in the bitmask?

> For rate/txpower there may be limits you cannot express with this, but
> must discover in some other way, or the implementation just clamps or
> something.

You're right, there needs to be more to the capabilities spec than that.
We may need to indicate either a range or an enumeration of allowable
values.

We may also need to indicate that a particular Tx flags setting is only
permitted at a particular Tx rate setting, or vice versa.

Dave

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