Plans for an online meeting regarding Radiotap
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]>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · 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.
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
2009/8/21 Johannes Berg <[email protected]>:
Quoted 8 lines · Gábor Stefanik
Quoted 3 lines
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.
Quoted 4 lines
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.)
Quoted 3 lines
johannes
Signature · 5 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · 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.
Quoted 8 lines
Quoted 3 lines
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/21 Johannes Berg <[email protected]>:
Quoted 16 lines · Gábor Stefanik
Quoted 7 lines
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.
Quoted 4 lines
Quoted 3 lines
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.
Quoted 8 lines
Quoted 4 lines
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 CTSTX_FLAGS & 0x0004: Use RTSTX_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
}Quoted 3 lines
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)?
Quoted 3 lines
johannes
Signature · 5 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Gábor Stefanik
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 CTSTX_FLAGS&0x0004: Use RTSTX_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.
Quoted 5 lines
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]>:
Quoted 5 lines · Gábor Stefanik
Quoted 4 lines
I've reworked RTS/CTS since then, just haven't got to sending a new proposal yet. The current plan is as follows:
Quoted 8 lines
Quoted 3 lines
TX_FLAGS&0x0002: Use CTSTX_FLAGS&0x0004: Use RTSTX_FLAGS&0x0020: Disable RTS/CTS usageSeems a bit strange, wouldn't setting neither RTS nor CTS have the effect? Seems like
0x20should 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.)
Quoted 12 lines
Quoted 6 lines
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
Signature · 5 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 69e28c910908211455u5dcd70f0u94eab510ab91a69a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: RTS/CTS + CTS-to-self
Quoted 15 lines · Gábor Stefanik
2009/8/21 Johannes Berg <[email protected]>:
Quoted 5 lines · Gábor Stefanik
Quoted 4 lines
I've reworked RTS/CTS since then, just haven't got to sending a new proposal yet. The current plan is as follows:
Quoted 8 lines
Quoted 3 lines
TX_FLAGS&0x0002: Use CTSTX_FLAGS&0x0004: Use RTSTX_FLAGS&0x0020: Disable RTS/CTS usageSeems a bit strange, wouldn't setting neither RTS nor CTS have the effect? Seems like
0x20should rather be "use automatic and ignore the other bits". Anyway, not appropriate here, you should just bring a new proposal.
Quoted 10 lines
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
0x20mean "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
Signature · 2 lines
David Young OJC Technologies [email protected] Urbana, IL * (217) 278-3933
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: RTS/CTS + CTS-to-self
Quoted 29 lines · David Young
Quoted 15 lines · Gábor Stefanik
2009/8/21 Johannes Berg <[email protected]>:
Quoted 5 lines · Gábor Stefanik
Quoted 4 lines
I've reworked RTS/CTS since then, just haven't got to sending a new proposal yet. The current plan is as follows:
Quoted 8 lines
Quoted 3 lines
TX_FLAGS&0x0002: Use CTSTX_FLAGS&0x0004: Use RTSTX_FLAGS&0x0020: Disable RTS/CTS usageSeems a bit strange, wouldn't setting neither RTS nor CTS have the effect? Seems like
0x20should rather be "use automatic and ignore the other bits". Anyway, not appropriate here, you should just bring a new proposal.Quoted 10 lines
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
0x20mean "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,
Quoted 8 lines
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.
Quoted 11 lines
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 [email protected] Urbana, IL * (217) 278-3933
Signature · 1 line
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
A message that is not in the archive (sent off-list or not yet received): 69e28c910908211547k7c48551aj4d9ac2d06ceeb6da-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: RTS/CTS + CTS-to-self
2009/8/22 Gábor Stefanik <[email protected]>:
Quoted 1 line · David Young
I think maybe you send to wrong people, I'm not above david ;)
Quoted 85 lines
Quoted 29 lines · Gábor Stefanik
Quoted 15 lines
2009/8/21 Johannes Berg <[email protected]>:
Quoted 5 lines · Gábor Stefanik
Quoted 4 lines
I've reworked RTS/CTS since then, just haven't got to sending a new proposal yet. The current plan is as follows:
Quoted 8 lines
Quoted 3 lines
TX_FLAGS&0x0002: Use CTSTX_FLAGS&0x0004: Use RTSTX_FLAGS&0x0020: Disable RTS/CTS usageSeems a bit strange, wouldn't setting neither RTS nor CTS have the effect? Seems like
0x20should rather be "use automatic and ignore the other bits". Anyway, not appropriate here, you should just bring a new proposal.Quoted 10 lines
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
0x20mean "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,
Quoted 8 lines
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.(quoted diff) +0
-2-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.
Quoted 11 lines
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 [email protected] Urbana, IL * (217) 278-3933--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
Signature · 2 lines
Regards dave
Re: RTS/CTS + CTS-to-self
In reply to a message not in the archiveQuoted 33 lines · Gábor Stefanik
Quoted 32 lines · David Young
Quoted 15 lines · Gábor Stefanik
2009/8/21 Johannes Berg <[email protected]>:
Quoted 5 lines · Gábor Stefanik
Quoted 4 lines
I've reworked RTS/CTS since then, just haven't got to sending a new proposal yet. The current plan is as follows:
Quoted 8 lines
Quoted 3 lines
TX_FLAGS&0x0002: Use CTSTX_FLAGS&0x0004: Use RTSTX_FLAGS&0x0020: Disable RTS/CTS usageSeems a bit strange, wouldn't setting neither RTS nor CTS have the effect? Seems like
0x20should rather be "use automatic and ignore the other bits". Anyway, not appropriate here, you should just bring a new proposal.Quoted 10 lines
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
0x20mean "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?
Quoted 8 lines
Quoted 5 lines
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
Signature · 2 lines
David Young OJC Technologies [email protected] Urbana, IL * (217) 278-3933
2009/8/22 Gábor Stefanik <[email protected]>:
Quoted 36 lines
2009/8/21 Johannes Berg <[email protected]>:
Quoted 5 lines · Gábor Stefanik
Quoted 4 lines
I've reworked RTS/CTS since then, just haven't got to sending a new proposal yet. The current plan is as follows:
Quoted 8 lines
Quoted 3 lines
TX_FLAGS&0x0002: Use CTSTX_FLAGS&0x0004: Use RTSTX_FLAGS&0x0020: Disable RTS/CTS usageSeems a bit strange, wouldn't setting neither RTS nor CTS have the effect? Seems like
0x20should 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
0x20mean "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.)Quoted 10 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 2 lines
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
Signature · 2 lines
Regards dave
Quoted 9 lines · G?bor Stefanik
Quoted 3 lines
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
Signature · 4 lines
Mike Kershaw/Dragorn <[email protected]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 "A baby seal walks into a club..."
A message that is not in the archive (sent off-list or not yet received): [email protected]
(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.)
Quoted 5 lines · 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:
...
Quoted 3 lines
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
Quoted 7 lines
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).
Quoted 1 line
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?
A message that is not in the archive (sent off-list or not yet received): EE141467-6B64-48B1-AC4C-EA5BD08BDB00-FrUbXkNCsVf2fBVCVOL8/[email protected]
Quoted 6 lines · Guy Harris
Quoted 3 lines
Wireshark:
Field 14: RX flags, with option to decode FCS instead Fields 15...17 skippedNo:
Quoted 8 lines
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.
Quoted 9 lines
Quoted 7 lines
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.