Plans for an online meeting regarding Radiotap

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 <netrolller.3d@gmail.com>

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 <netrolller.3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Plans for an online meeting regarding Radiotap

[Johannes Berg]

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

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

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

Re: Plans for an online meeting regarding Radiotap

[Johannes Berg]

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

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

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

Re: Plans for an online meeting regarding Radiotap

[Gábor Stefanik]

2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
> 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. :-)

Re: Plans for an online meeting regarding Radiotap

[Gábor Stefanik]

2009/8/21 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> 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. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Plans for an online meeting regarding Radiotap

[Johannes Berg]

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

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

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

Re: Plans for an online meeting regarding Radiotap

[Johannes Berg]

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

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

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

Re: Plans for an online meeting regarding Radiotap

[Gábor Stefanik]

2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
> 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. :-)

Re: Plans for an online meeting regarding Radiotap

[Gábor Stefanik]

2009/8/21 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> 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. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Plans for an online meeting regarding Radiotap

[Johannes Berg]

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

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

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

Re: Plans for an online meeting regarding Radiotap

[Johannes Berg]

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

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

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

Re: Plans for an online meeting regarding Radiotap

[Gábor Stefanik]

2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
> 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. :-)

Re: Plans for an online meeting regarding Radiotap

[Gábor Stefanik]

2009/8/21 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> 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. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RTS/CTS + CTS-to-self

[David Young]

On Fri, Aug 21, 2009 at 11:55:27PM +0200, Gábor Stefanik wrote:
> 2009/8/21 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> > 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.)

Gábor,

Please explain what is wrong with a two-bit (four-state) field like
this?

00: Let the hardware, firmware, or device driver decide.  (I.e., same as
    omitting Tx flags altogether.)
01: Send RTS/CTS.
10: Send CTS to self.
11: Forbid CTS-to-self and RTS/CTS.

This is just a small modification to one of your previous proposals.

(Note that I have trimmed the lengthy To: line!)

Dave

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

Re: RTS/CTS + CTS-to-self

[Gábor Stefanik]

On Sat, Aug 22, 2009 at 12:35 AM, David Young<dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Aug 21, 2009 at 11:55:27PM +0200, Gábor Stefanik wrote:
>> 2009/8/21 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
>> > 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.)
>
> Gábor,
>
> Please explain what is wrong with a two-bit (four-state) field like
> this?
>
> 00: Let the hardware, firmware, or device driver decide.  (I.e., same as
>    omitting Tx flags altogether.)
> 01: Send RTS/CTS.
> 10: Send CTS to self.
> 11: Forbid CTS-to-self and RTS/CTS.

The 11 case is illogical. The logical meaning of 11 would be "use
both", but it actually means "use neither" - just the opposite.

However, now that I think of it - doesn't an RTS handshake use both
RTS and CTS packets?
In that case, the following layout makes sense:

First bit: use RTS.
Second bit: use CTS.

00: Auto-select
01: Use neither (this would logically mean "Use RTS, but not CTS" -
which is impossible.)
10: CTS-to-self (which uses only CTS, and no RTS frames are sent)
11: RTS handshake (uses both RTS and CTS, hence both bits set)

This has the following advantages:
-An all-zeros TX flags field is equivalent to having no TX flags field
in the header.
-The bits represent what packets are used by each protection method.
-No settings map to their logical opposites.

An alternative interpretation of the same scheme is this:

Second bit: use protection.
First bit: if protection is used, use RTS handshake; otherwise disable
auto-selection.

This produces the same mapping as the first.

>
> This is just a small modification to one of your previous proposals.
>
> (Note that I have trimmed the lengthy To: line!)
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933
>



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

Re: RTS/CTS + CTS-to-self

[Dave Young]

2009/8/22 Gábor Stefanik <netrolller.3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> On Sat, Aug 22, 2009 at 12:35 AM, David Young<dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> wrote:

I think maybe you send to wrong people, I'm not above david ;)

>> On Fri, Aug 21, 2009 at 11:55:27PM +0200, Gábor Stefanik wrote:
>>> 2009/8/21 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
>>> > 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.)
>>
>> Gábor,
>>
>> Please explain what is wrong with a two-bit (four-state) field like
>> this?
>>
>> 00: Let the hardware, firmware, or device driver decide.  (I.e., same as
>>    omitting Tx flags altogether.)
>> 01: Send RTS/CTS.
>> 10: Send CTS to self.
>> 11: Forbid CTS-to-self and RTS/CTS.
>
> The 11 case is illogical. The logical meaning of 11 would be "use
> both", but it actually means "use neither" - just the opposite.
>
> However, now that I think of it - doesn't an RTS handshake use both
> RTS and CTS packets?
> In that case, the following layout makes sense:
>
> First bit: use RTS.
> Second bit: use CTS.
>
> 00: Auto-select
> 01: Use neither (this would logically mean "Use RTS, but not CTS" -
> which is impossible.)
> 10: CTS-to-self (which uses only CTS, and no RTS frames are sent)
> 11: RTS handshake (uses both RTS and CTS, hence both bits set)
>
> This has the following advantages:
> -An all-zeros TX flags field is equivalent to having no TX flags field
> in the header.
> -The bits represent what packets are used by each protection method.
> -No settings map to their logical opposites.
>
> An alternative interpretation of the same scheme is this:
>
> Second bit: use protection.
> First bit: if protection is used, use RTS handshake; otherwise disable
> auto-selection.
>
> This produces the same mapping as the first.
>
>>
>> This is just a small modification to one of your previous proposals.
>>
>> (Note that I have trimmed the lengthy To: line!)
>>
>> Dave
>>
>> --
>> David Young             OJC Technologies
>> dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>



-- 
Regards
dave

Re: RTS/CTS + CTS-to-self

[David Young]

On Sat, Aug 22, 2009 at 12:47:19AM +0200, Gábor Stefanik wrote:
> On Sat, Aug 22, 2009 at 12:35 AM, David Young<dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> wrote:
> > On Fri, Aug 21, 2009 at 11:55:27PM +0200, Gábor Stefanik wrote:
> >> 2009/8/21 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
> >> > 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.)
> >
> > Gábor,
> >
> > Please explain what is wrong with a two-bit (four-state) field like
> > this?
> >
> > 00: Let the hardware, firmware, or device driver decide.  (I.e., same as
> >    omitting Tx flags altogether.)
> > 01: Send RTS/CTS.
> > 10: Send CTS to self.
> > 11: Forbid CTS-to-self and RTS/CTS.
> 
> The 11 case is illogical. The logical meaning of 11 would be "use
> both", but it actually means "use neither" - just the opposite.

You may have misunderstood.  When I say to treat it as a two-bit field,
I mean to treat it as an integer that is two bits wide.  That is, I am
not talking about flags any longer.  I may as well have written the
values in decimal:

0: Let the hardware, firmware, or device driver decide.  (I.e., same as
   omitting Tx flags altogether.)
1: Send RTS/CTS.
2: Send CTS to self.
3: Forbid CTS-to-self and RTS/CTS.

I don't care too much which value maps to what function, except that 0
must mean "don't care."  I think we agree about that much?

According to my notes, somebody may already use Tx flags 0x2 and 0x4 to
indicate CTS protection and RTS/CTS handshake, respectively, so this
assignment may be most practical:

Tx Protection Field, Bits [3:2]
Values:
        0: Let the hardware, firmware, or device driver decide.  (I.e., same as
           omitting Tx flags altogether.)
        1: Send CTS to self.
        2: Send RTS/CTS.
        3: Forbid CTS-to-self and RTS/CTS.

Ok?

Dave

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

Re: Plans for an online meeting regarding Radiotap

[Dave Young]

2009/8/22 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
>> 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

Re: Plans for an online meeting regarding Radiotap

[Dave Young]

2009/8/22 Gábor Stefanik <netrolller.3d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
> 2009/8/21 Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>:
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Plans for an online meeting regarding Radiotap

[Mike Kershaw]

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

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 <dragorn@kismetwireless.net>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

"A baby seal walks into a club..."

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Plans for an online meeting regarding Radiotap

[Mike Kershaw]

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

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 <dragorn-8I8a9W+rkIX1ZkIrOfZKgqxOck334EZe@public.gmane.org>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

"A baby seal walks into a club..."

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Plans for an online meeting regarding Radiotap

[Guy Harris]

(Removed mailing lists other than radiotap, fixed Damien Bergamini's  
address, and removed the "other" David Young - the right David Young  
is on the radiotap mailing list.)

On Aug 21, 2009, at 7:31 AM, Gábor Stefanik wrote:

> 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:

	...

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

No:

Fields 15...17: not implemented, so if any of them are present, no  
later fields are dissected

Also:

Tcpdump top-of-tree at tcpdump.org:

Fields 14...17: not implemented, so if any of them are present, no  
later fields are dissected
Field 18: extended channel

> 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)

...and top-of-tree tcpdump.org tcpdump (taken from FreeBSD's tcpdump).

> Field 19: RSSI (OpenBSD's field 16 moved to field ID 19 to avoid  
> collisions)

So what does the value of that field mean?  The 802.11 spec just says

	The RSSI is an optional parameter that has a value of 0 through RSSI  
Max. This parameter is a measure by
the PHY of the energy observed at the antenna used to receive the  
current PPDU. RSSI shall be measured
between the beginning of the SFD and the end of the PLCP HEC. RSSI is  
intended to be used in a relative
manner. Absolute accuracy of the RSSI reading is not specified.

so its value doesn't intrinsically mean anything - the only thing you  
can do is say that, if the RSSI value is greater for packet B than for  
packet A, there was higher energy at the antenna when packet B was  
received than when packet A was received.

If a driver supplies IEEE80211_RADIOTAP_DBM_ANTSIGNAL or  
IEEE80211_RADIOTAP_DB_ANTSIGNAL, is the RSSI useful?

Are there any drivers that cannot supply  
IEEE80211_RADIOTAP_DBM_ANTSIGNAL or IEEE80211_RADIOTAP_DB_ANTSIGNAL?

Re: Plans for an online meeting regarding Radiotap

[Guy Harris]

On Aug 24, 2009, at 11:55 AM, Guy Harris wrote:

>> Wireshark:
>> Field 14: RX flags, with option to decode FCS instead
>> Fields 15...17 skipped
>
> No:
>
> Fields 15...17: not implemented, so if any of them are present, no  
> later fields are dissected
>
> Also:
>
> Tcpdump top-of-tree at tcpdump.org:
>
> Fields 14...17: not implemented, so if any of them are present, no  
> later fields are dissected
> Field 18: extended channel

Although field 18 is, I think, used only by FreeBSD, and it doesn't  
use fields 15-17, so those won't cause a problem for field 18.

>> 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)
>
> ...and top-of-tree tcpdump.org tcpdump (taken from FreeBSD's tcpdump).

Sorry, that was a bit unclear - "...and top-of-tree tcpdump.org  
tcpdump (taken from FreeBSD's tcpdump)" applies to field 18, not to  
the other fields.

We should probably add support for field 14 (as defined by the  
standard) to tcpdump.