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 <[email protected]>
On Fri, 2009-08-21 at 17:04 +0200, Gábor Stefanik wrote:
> 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
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.
> 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
2009/8/21 Johannes Berg <[email protected]>:
> On Fri, 2009-08-21 at 16:41 +0200, G?bor Stefanik wrote:
>
>> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
2009/8/21 Johannes Berg <[email protected]>:
> On Fri, 2009-08-21 at 17:04 +0200, G?bor Stefanik wrote:
>
>> 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
>
> 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.)
>
>> 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. :-)
2009/8/21 Johannes Berg <[email protected]>:
> On Fri, 2009-08-21 at 16:31 +0200, G?bor Stefanik wrote:
>
>> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Fri, Aug 21, 2009 at 05:04:20PM +0200, G?bor Stefanik wrote:
> > 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
--
Mike Kershaw/Dragorn <[email protected]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
"A baby seal walks into a club..."
On Fri, 2009-08-21 at 16:31 +0200, Gábor Stefanik wrote:
> 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.
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.
johannes
On Fri, 2009-08-21 at 16:41 +0200, Gábor Stefanik wrote:
> 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. Besides,
you're supposed to make at least two implementations when proposing a
standard field.
johannes
2009/8/22 Gábor Stefanik <[email protected]>:
> 2009/8/21 Johannes Berg <[email protected]>:
>> On Fri, 2009-08-21 at 17:04 +0200, Gábor Stefanik wrote:
>>
>>> 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
>>
>> 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.)
>
>>
>>> 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
--
Regards
dave