Plans for an online meeting regarding Radiotap

[Gábor Stefanik]

Radiotap is a de-facto standard for 802.11 frame injection and reception.
Up to field ID 13, it can truly considered a standard (all current
implementations
agree on fields 1-13), but after that, implementations diverge widely.

Here is a map of how current implementations define field IDs 14 and up:

Linux (both mac80211 & madwifi, not sure about libertas) & NetBSD:
Field 14: RX flags (standardized field)
Field 15: TX flags
Field 16: RTS retries
Field 17: Data retries

FreeBSD:
Fields 14...17 skipped (incliding standardized field 14), field 18:
Extended channel

OpenBSD:
Field 14: FCS of the frame (clashes with standard - field 14 is defined
as RX flags!)
Field 15: Hardware queue
Field 16: RSSI

DragonFly BSD: No fields above 13 implemented.

Aircrack-ng:
Field 14: RX flags (as in the standard)
Field 15: TX flags

CACE AirPcap software:
Field 14: FCS of the frame (clashes with standard; the FCS is also appended
to the end of the packet, so this usage is unneeded)

Wireshark:
Field 14: RX flags, with option to decode FCS instead
Fields 15...17 skipped
Field 18: Extended channel

Radiotap fields 14 and up need to be sorted out to allow further
advancements
of the standard. In the current state, essentially no fields can be
added without
risking a collision between implementations. To remedy this, I would
like to propose
an online mini-summit to be held on Freenode, with the goal of defining
a standard
way to use fields 14 and up.
The summit is to be held in IRC channel #radiotap, where interested
parties can join
the discussion and propose changes. My preferred time for this event is
August 25, 2009, 18:00 GMT; please let me know if this date is
unsuitable for any of
you, and I will try to find a better time for the summit when everyone
interested can attend.

My current proposal for the future standard field ordering beyond field 14:

Field 14: RX flags (as defined by the standard)
Field 15: TX flags (as used by Linux, NetBSD and aircrack-ng)
Field 16: RTS retry count (as used by Linux and NetBSD)
Field 17: Data retry count (as used by Linux and NetBSD)
Field 18: Extended channel (as used by FreeBSD and Wireshark)
Field 19: RSSI (OpenBSD's field 16 moved to field ID 19 to avoid collisions)

In addition, the following new fields may be worth addition to the standard:
RTS threshold, Fragmentation threshold, Extended rate (with MCS index
support).
I'm deliberately not assigning field numbers to these proposed fields
yet to prevent
early, divergent implementations of them; the field IDs for these should
be decided
during the summit.

I'm for dropping the following fields, please let me know during the summit
if there are any use cases for them:
-FCS of the frame (if we have FCS data, then it should be appended to the
end of the frame, not put into the header)
-Hardware queue (I don't see the point of this... maybe a full QoS
control field
would be needed instead)

Hope to see you on Freenode at the set date. Again, if the time is a
problem,
respond, and I will try to find a better time.

Sincerely,
Gábor Stefanik <***@gmail.com>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gábor Stefanik]

My intention with the meeting is to form an actual proposal that all
implementors can agree on. We can produce proposals, and even new
standardized fields to no avail, as some implementors (especially
OpenBSD) appear to be stuck with implementations that collide with the
standard. These implementors need to be "awakened" and entered into
the discussions before anything can be done.

There's nothing the standard can do about that. Like I said, we've
talked about that enough in my opinion.

Your own proposal had technical flaws (and in my opinion tried to do too
much at a time) that you haven't addressed -- doing that would be much
more productive than any such meeting.

What technical flaws are you trying to point out exactly? (The TX
flags field? My point is that it's worthless to "standardize" TX flags
by extending it and moving to "Defined fields" if noone is willing to
implement it.)

But people are already implementing it, and if they do something else
that's their problem. The flaw I'm thinking of was over the RTS/CTS
handling where some people (including myself) had comments.

I've reworked RTS/CTS since then, just haven't got to sending a new
proposal yet. The current plan is as follows:

TX_FLAGS & 0x0002: Use CTS
TX_FLAGS & 0x0004: Use RTS
TX_FLAGS & 0x0020: Disable RTS/CTS usage

Or, in more C++-like notation:
switch (TX_FLAGS & 0x0026) {
case 0x0002:
Use CTS;
break;
case 0x0004:
case 0x0006:
Use RTS;
break;
case 0x0020:
Disable RTS/CTS usage;
break;
default:
fall back to automatic selection
}

Besides,
you're supposed to make at least two implementations when proposing a
standard field.

If I remember correctly, I made an implementation for the Linux kernel
(a generator-side implementation) and one for Wireshark (a parser-side
implementation). Or should I make two generator-side implementations
according to the requirement (e.g. one for Linux, another for
OpenBSD)?

johannes

[Gábor Stefanik]

Post by Gábor Stefanik
Hope to see you on Freenode at the set date. Again, if the time is a
problem, respond, and I will try to find a better time.

I don't think there's any need to have an IRC meeting. We've hashed out
the way forward multiple times on the radiotap list. What is missing now
isn't a consensus of how do things, but proposals and implementations.

My intention with the meeting is to form an actual proposal that all
implementors can agree on. We can produce proposals, and even new
standardized fields to no avail, as some implementors (especially
OpenBSD) appear to be stuck with implementations that collide with the
standard. These implementors need to be "awakened" and entered into
the discussions before anything can be done.

Your own proposal had technical flaws (and in my opinion tried to do too
much at a time) that you haven't addressed -- doing that would be much
more productive than any such meeting.

What technical flaws are you trying to point out exactly? (The TX
flags field? My point is that it's worthless to "standardize" TX flags
by extending it and moving to "Defined fields" if noone is willing to
implement it.)

johannes

[Gábor Stefanik]

Post by Gábor Stefanik
I've reworked RTS/CTS since then, just haven't got to sending a new
TX_FLAGS & 0x0002: Use CTS
TX_FLAGS & 0x0004: Use RTS
TX_FLAGS & 0x0020: Disable RTS/CTS usage

Seems a bit strange, wouldn't setting neither RTS nor CTS have the
effect? Seems like 0x20 should rather be "use automatic and ignore the
other bits". Anyway, not appropriate here, you should just bring a new
proposal.

The point is that if all bits are 0, auto-setup is used. The problem
with my original proposal (using two bits) was that an all-zero value
had different effect than not including the TX flags field (and simply
swapping "none" and "auto" would result in an illogicality where what
would logically be "use both" would become "use neither" - just the
opposite of its logical meaning). Making 0x20 mean "Auto-select
RTS/CTS", interpreting all-zeros as "Use neither", would have the same
problem as my proposal - all-zeros is different from a missing field.
(An empty, zeroed field 15 should have no effect on the process,
behaving as if field 15 was not present in the header.)

Post by Gábor Stefanik
If I remember correctly, I made an implementation for the Linux kernel
(a generator-side implementation) and one for Wireshark (a parser-side
implementation). Or should I make two generator-side implementations
according to the requirement (e.g. one for Linux, another for
OpenBSD)?

No, that was ok, I just meant that therefore by definition it can't be a
problem of lack of implementations.
johannes

[Dave Young]

Post by Gábor Stefanik

Post by Gábor Stefanik
I've reworked RTS/CTS since then, just haven't got to sending a new
TX_FLAGS & 0x0002: Use CTS
TX_FLAGS & 0x0004: Use RTS
TX_FLAGS & 0x0020: Disable RTS/CTS usage

Seems a bit strange, wouldn't setting neither RTS nor CTS have the
effect? Seems like 0x20 should rather be "use automatic and ignore the
other bits". Anyway, not appropriate here, you should just bring a new
proposal.

The point is that if all bits are 0, auto-setup is used. The problem
with my original proposal (using two bits) was that an all-zero value
had different effect than not including the TX flags field (and simply
swapping "none" and "auto" would result in an illogicality where what
would logically be "use both" would become "use neither" - just the
opposite of its logical meaning). Making 0x20 mean "Auto-select
RTS/CTS", interpreting all-zeros as "Use neither", would have the same
problem as my proposal - all-zeros is different from a missing field.
(An empty, zeroed field 15 should have no effect on the process,
behaving as if field 15 was not present in the header.)

Post by Gábor Stefanik
If I remember correctly, I made an implementation for the Linux kernel
(a generator-side implementation) and one for Wireshark (a parser-side
implementation). Or should I make two generator-side implementations
according to the requirement (e.g. one for Linux, another for
OpenBSD)?

No, that was ok, I just meant that therefore by definition it can't be a
problem of lack of implementations.
johannes

--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

Here also, please fix your cc-list, I'm not the david what you want to send to

[Mike Kershaw]

Post by Gábor Stefanik

Besides,
you're supposed to make at least two implementations when proposing a
standard field.

If I remember correctly, I made an implementation for the Linux kernel
(a generator-side implementation) and one for Wireshark (a parser-side
implementation). Or should I make two generator-side implementations
according to the requirement (e.g. one for Linux, another for
OpenBSD)?

Once there's a spec that's a little more stable I can add it to lorcon, so
that will give you 2 userspace implementations for tx (assuming aircrack
adopts it) with different authors.

-m