* RFC: radiotap discrepancy in Linux vs OpenBSD
@ 2007-03-26 3:24 Pavel Roskin
2007-03-26 3:37 ` David Young
2007-03-26 3:38 ` David Young
0 siblings, 2 replies; 8+ messages in thread
From: Pavel Roskin @ 2007-03-26 3:24 UTC (permalink / raw)
To: linux-wireless; +Cc: David Young, Scott Raynel
Hello!
I have noticed two different incompatible changes to enum
ieee80211_radiotap_type in ieee80211_radiotap.h.
One is found in the current wireless-2.6.git:
IEEE80211_RADIOTAP_RX_FLAGS = 14,
IEEE80211_RADIOTAP_TX_FLAGS = 15,
IEEE80211_RADIOTAP_RTS_RETRIES = 16,
IEEE80211_RADIOTAP_DATA_RETRIES = 17,
It was added together with Marvell Libertas USB driver.
Another set of the flags can be found in CVS OpenBSD:
IEEE80211_RADIOTAP_FCS = 14,
IEEE80211_RADIOTAP_HWQUEUE = 15,
IEEE80211_RADIOTAP_RSSI = 16,
Actually, there is a reference to IEEE80211_RADIOTAP_FCS in Linux, but only in a
comment.
IEEE80211_RADIOTAP_FCS is not used in any driver (apparently, it's better to
keep FCS in the end of the frame, not in the header), but the other two flags
are used in more than one driver.
I think Marvell developers could act gracefully and push the flags it introduces
to higher numbers. Doing something like that on the OpenBSD side would be
harder. I would also like to see joining Rx and Tx flags into one 32-bit
value.
But we need some coordination when new fields are added to the protocol.
Radiotap is better than other wireless capture headers because it's better
documented and more extensible. But extending it in an uncontrolled way would
ruin the standard.
We could consider introducing driver specific area in the header. For instance,
Atheros chips may allow the userspace to specify a set of rates at which the
transmission will be attempted. Uncalibrated RSSI may also be a candidate for
the driver-specific data if OpenBSD can be persuaded to abandon its present
number.
It's important that presence of driver specific fields doesn't break parsing of
the standard fields, even if new fields are made standard. I think driver
specific flags don't belong to the it_present bitmap, but should go to the
beginning of the driver specific area.
--
Regards,
Pavel Roskin
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: RFC: radiotap discrepancy in Linux vs OpenBSD 2007-03-26 3:24 RFC: radiotap discrepancy in Linux vs OpenBSD Pavel Roskin @ 2007-03-26 3:37 ` David Young 2007-03-26 22:45 ` Pavel Roskin 2007-03-26 3:38 ` David Young 1 sibling, 1 reply; 8+ messages in thread From: David Young @ 2007-03-26 3:37 UTC (permalink / raw) To: Pavel Roskin; +Cc: linux-wireless, Scott Raynel On Sun, Mar 25, 2007 at 11:24:16PM -0400, Pavel Roskin wrote: > Hello! The place to discuss this is the mailing list radiotap@ojctech.com, which I have cc'd. Subscribe at <http://mail.ojctech.com/mailman/listinfo/radiotap>. Please feel free to circulate the URL. > I have noticed two different incompatible changes to enum > ieee80211_radiotap_type in ieee80211_radiotap.h. > > One is found in the current wireless-2.6.git: > > IEEE80211_RADIOTAP_RX_FLAGS = 14, > IEEE80211_RADIOTAP_TX_FLAGS = 15, > IEEE80211_RADIOTAP_RTS_RETRIES = 16, > IEEE80211_RADIOTAP_DATA_RETRIES = 17, These fields are slated to become part of the standard, I just haven't got around to updating the manual page, yet. I have time to do that tonight. > It was added together with Marvell Libertas USB driver. > Another set of the flags can be found in CVS OpenBSD: > > IEEE80211_RADIOTAP_FCS = 14, > IEEE80211_RADIOTAP_HWQUEUE = 15, > IEEE80211_RADIOTAP_RSSI = 16, These fields are not part of the standard, and they will not become part of the standard with these numbers. This is the first time I have ever heard of HWQUEUE and RSSI, actually. What are they for? > I think Marvell developers could act gracefully and push the flags it introduces > to higher numbers. Doing something like that on the OpenBSD side would be > harder. I would also like to see joining Rx and Tx flags into one 32-bit > value. > But we need some coordination when new fields are added to the protocol. Right. People must coordinate on the radiotap list. > Uncalibrated RSSI may also be a candidate for > the driver-specific data if OpenBSD can be persuaded to abandon its present > number. OpenBSD will need to abandon its present numbers in order to stay compatible with tcpdump and wireshark. > It's important that presence of driver specific fields doesn't break parsing of > the standard fields, even if new fields are made standard. I think driver > specific flags don't belong to the it_present bitmap, but should go to the > beginning of the driver specific area. You are right that the driver-specific fields cannot go in the bitmap. Dave -- David Young OJC Technologies dyoung@ojctech.com Urbana, IL * (217) 278-3933 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: radiotap discrepancy in Linux vs OpenBSD 2007-03-26 3:37 ` David Young @ 2007-03-26 22:45 ` Pavel Roskin 2007-03-28 18:04 ` [Radiotap] " Marcelo Tosatti 0 siblings, 1 reply; 8+ messages in thread From: Pavel Roskin @ 2007-03-26 22:45 UTC (permalink / raw) To: David Young; +Cc: linux-wireless, Scott Raynel, radiotap On Sun, 2007-03-25 at 22:37 -0500, David Young wrote: > > One is found in the current wireless-2.6.git: > > > > IEEE80211_RADIOTAP_RX_FLAGS = 14, > > IEEE80211_RADIOTAP_TX_FLAGS = 15, > > IEEE80211_RADIOTAP_RTS_RETRIES = 16, > > IEEE80211_RADIOTAP_DATA_RETRIES = 17, > > These fields are slated to become part of the standard, I just haven't got > around to updating the manual page, yet. I have time to do that tonight. OK. I was wrong to assume that non-standard fields were introduced on the Linux side. > > Another set of the flags can be found in CVS OpenBSD: > > > > IEEE80211_RADIOTAP_FCS = 14, > > IEEE80211_RADIOTAP_HWQUEUE = 15, > > IEEE80211_RADIOTAP_RSSI = 16, > > These fields are not part of the standard, and they will not become part > of the standard with these numbers. This is the first time I have ever > heard of HWQUEUE and RSSI, actually. What are they for? IEEE80211_RADIOTAP_HWQUEUE specifies the hardware queue. This is used in the drivers for Atheros and Intel ipw3945 to report transmitted frames to the userspace. In case of Atheros, the value would always be 0, but the way it's written (HAL_TX_QUEUE_ID_DATA_MIN), I assume the value is supposed to be hardware specific rather than a number from the 802.11e standard. Other values in the same enum are 6, 7, 8 and 9. In case of the ipw3945 driver, it's always 0, but it's used as an index in an array of size 4, so at least it a number from 0 to 3. The description in ieee80211_radiotap.h is: "A specific hardware queue (used by WME)" and it's one 8-bit integer. IEEE80211_RADIOTAP_HWQUEUE is described as "A relative Received Signal Strength Index" and it's two 8-bit integers, RSSI and max RSSI. It's used by many drivers and includes uncalibrated signal data. It looks like noise data is not included. -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Radiotap] Re: RFC: radiotap discrepancy in Linux vs OpenBSD 2007-03-26 22:45 ` Pavel Roskin @ 2007-03-28 18:04 ` Marcelo Tosatti 2007-03-28 20:33 ` Pavel Roskin 0 siblings, 1 reply; 8+ messages in thread From: Marcelo Tosatti @ 2007-03-28 18:04 UTC (permalink / raw) To: Pavel Roskin; +Cc: David Young, linux-wireless, Scott Raynel, radiotap On Mon, Mar 26, 2007 at 06:45:49PM -0400, Pavel Roskin wrote: > On Sun, 2007-03-25 at 22:37 -0500, David Young wrote: > > > > One is found in the current wireless-2.6.git: > > > > > > IEEE80211_RADIOTAP_RX_FLAGS = 14, > > > IEEE80211_RADIOTAP_TX_FLAGS = 15, > > > IEEE80211_RADIOTAP_RTS_RETRIES = 16, > > > IEEE80211_RADIOTAP_DATA_RETRIES = 17, > > > > These fields are slated to become part of the standard, I just haven't got > > around to updating the manual page, yet. I have time to do that tonight. > > OK. I was wrong to assume that non-standard fields were introduced on > the Linux side. I mentioned those in the past to David Young, but I forgot to resend them to the radiotap list. >From what I gather he's OK with them. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Radiotap] Re: RFC: radiotap discrepancy in Linux vs OpenBSD 2007-03-28 18:04 ` [Radiotap] " Marcelo Tosatti @ 2007-03-28 20:33 ` Pavel Roskin 0 siblings, 0 replies; 8+ messages in thread From: Pavel Roskin @ 2007-03-28 20:33 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: David Young, linux-wireless, Scott Raynel, radiotap On Wed, 2007-03-28 at 15:04 -0300, Marcelo Tosatti wrote: > On Mon, Mar 26, 2007 at 06:45:49PM -0400, Pavel Roskin wrote: > > On Sun, 2007-03-25 at 22:37 -0500, David Young wrote: > > > > > > One is found in the current wireless-2.6.git: > > > > > > > > IEEE80211_RADIOTAP_RX_FLAGS = 14, > > > > IEEE80211_RADIOTAP_TX_FLAGS = 15, > > > > IEEE80211_RADIOTAP_RTS_RETRIES = 16, > > > > IEEE80211_RADIOTAP_DATA_RETRIES = 17, > > > > > > These fields are slated to become part of the standard, I just haven't got > > > around to updating the manual page, yet. I have time to do that tonight. > > > > OK. I was wrong to assume that non-standard fields were introduced on > > the Linux side. > > I mentioned those in the past to David Young, but I forgot to resend > them to the radiotap list. Then we need to remove IEEE80211_RADIOTAP_FCS from Linux ieee80211_radiotap.h. It's only present in a comment, but it's a comment that can be harmful. I could submit a patch, but it would conflict with a patch that does sparse annotation. OK, I'll submit both. -- Regards, Pavel Roskin ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: radiotap discrepancy in Linux vs OpenBSD 2007-03-26 3:24 RFC: radiotap discrepancy in Linux vs OpenBSD Pavel Roskin 2007-03-26 3:37 ` David Young @ 2007-03-26 3:38 ` David Young 2007-03-26 15:41 ` Luis R. Rodriguez 1 sibling, 1 reply; 8+ messages in thread From: David Young @ 2007-03-26 3:38 UTC (permalink / raw) To: Pavel Roskin; +Cc: linux-wireless, Scott Raynel, radiotap On Sun, Mar 25, 2007 at 11:24:16PM -0400, Pavel Roskin wrote: > Hello! (Oops, this time cc'd radiotap.) The place to discuss this is the mailing list radiotap@ojctech.com, which I have cc'd. Subscribe at <http://mail.ojctech.com/mailman/listinfo/radiotap>. Please feel free to circulate the URL. > I have noticed two different incompatible changes to enum > ieee80211_radiotap_type in ieee80211_radiotap.h. > > One is found in the current wireless-2.6.git: > > IEEE80211_RADIOTAP_RX_FLAGS = 14, > IEEE80211_RADIOTAP_TX_FLAGS = 15, > IEEE80211_RADIOTAP_RTS_RETRIES = 16, > IEEE80211_RADIOTAP_DATA_RETRIES = 17, These fields are slated to become part of the standard, I just haven't got around to updating the manual page, yet. I have time to do that tonight. > It was added together with Marvell Libertas USB driver. > Another set of the flags can be found in CVS OpenBSD: > > IEEE80211_RADIOTAP_FCS = 14, > IEEE80211_RADIOTAP_HWQUEUE = 15, > IEEE80211_RADIOTAP_RSSI = 16, These fields are not part of the standard, and they will not become part of the standard with these numbers. This is the first time I have ever heard of HWQUEUE and RSSI, actually. What are they for? > I think Marvell developers could act gracefully and push the flags it introduces > to higher numbers. Doing something like that on the OpenBSD side would be > harder. I would also like to see joining Rx and Tx flags into one 32-bit > value. > But we need some coordination when new fields are added to the protocol. Right. People must coordinate on the radiotap list. > Uncalibrated RSSI may also be a candidate for > the driver-specific data if OpenBSD can be persuaded to abandon its present > number. OpenBSD will need to abandon its present numbers in order to stay compatible with tcpdump and wireshark. > It's important that presence of driver specific fields doesn't break parsing of > the standard fields, even if new fields are made standard. I think driver > specific flags don't belong to the it_present bitmap, but should go to the > beginning of the driver specific area. You are right that the driver-specific fields cannot go in the bitmap. Dave -- David Young OJC Technologies dyoung@ojctech.com Urbana, IL * (217) 278-3933 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: radiotap discrepancy in Linux vs OpenBSD 2007-03-26 3:38 ` David Young @ 2007-03-26 15:41 ` Luis R. Rodriguez 2007-03-26 16:59 ` David Young 0 siblings, 1 reply; 8+ messages in thread From: Luis R. Rodriguez @ 2007-03-26 15:41 UTC (permalink / raw) To: David Young; +Cc: Pavel Roskin, linux-wireless, Scott Raynel, radiotap CC'ing radiotap list, this time with your comments inline. On 3/25/07, David Young <dyoung@pobox.com> wrote: > On Sun, Mar 25, 2007 at 11:24:16PM -0400, Pavel Roskin wrote: > > Hello! > > (Oops, this time cc'd radiotap.) > > The place to discuss this is the mailing list > radiotap@ojctech.com, which I have cc'd. Subscribe at > <http://mail.ojctech.com/mailman/listinfo/radiotap>. Please feel free > to circulate the URL. > > > I have noticed two different incompatible changes to enum > > ieee80211_radiotap_type in ieee80211_radiotap.h. > > > > One is found in the current wireless-2.6.git: > > > > IEEE80211_RADIOTAP_RX_FLAGS = 14, > > IEEE80211_RADIOTAP_TX_FLAGS = 15, > > IEEE80211_RADIOTAP_RTS_RETRIES = 16, > > IEEE80211_RADIOTAP_DATA_RETRIES = 17, > > These fields are slated to become part of the standard, I just haven't got > around to updating the manual page, yet. I have time to do that tonight. > > > It was added together with Marvell Libertas USB driver. > > > Another set of the flags can be found in CVS OpenBSD: > > > > IEEE80211_RADIOTAP_FCS = 14, > > IEEE80211_RADIOTAP_HWQUEUE = 15, > > IEEE80211_RADIOTAP_RSSI = 16, > > These fields are not part of the standard, and they will not become part > of the standard with these numbers. This is the first time I have ever > heard of HWQUEUE and RSSI, actually. What are they for? RSSI is Received Signal Strength Indication. Its a measurement of the received radio signal strength. Unfortunately though RSSI units used are arbitrary and the maximum value differs amongst chipsets. From wikipedia: -- RSSI measurements will vary from 0 to 255 depending on the vendor. It consists of a one byte integer value. A value of 1 will indicate the minimum signal strength detectable by the wireless card, while 0 indicates no signal. The value has a maximum of RSSI_Max. For example, Cisco Systems cards will return a RSSI of 0 to 100. In this case, the RSSI_Max is 100. The Cisco card can report 101 distinct power levels. Another popular Wi-Fi chipset is made by Atheros. An Atheros based card will return a RSSI value of 0 to 60. -- As Samuel Barber had recommended before, we should probably instead adopt RCPI. Quoting from his e-mail: --- Here is the full text of the definition from 802.11k draft 5.0: received channel power indicator (RCPI): An indication of the total channel power (signal, noise, and interference) of a received IEEE 802.11 frame measured on a single channel and at the antenna connector used to receive the frame. The RCPI indicator is a measure of the received RF power in the selected channel for a received frame. This parameter shall be a measure by the PHY sublayer of the received RF power in the channel measured over the entire received frame or by other equivalent means which meet the specified accuracy. RCPI shall be a monotonically increasing, logarithmic function of the received power level defined in dBm. The allowed values for the Received Channel Power Indicator (RCPI) parameter shall be an 8 bit value in the range from 0 through 220, with indicated values rounded to the nearest 0.5 dB as follows: 0: Power < -110 dBm 1: Power = -109.5 dBm 2: Power = -109.0 dBm and so on where RCPI = int{(Power in dBm +110)*2} for 0dbm > Power > -110dBm 220: Power > -0 dBm 221-254: reserved 255: Measurement not available RCPI shall equal the received RF power within an accuracy of +/-5 dB (95% confidence interval) within the specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver noise equivalent bandwidth equal to the channel bandwidth multiplied by 1.1. -- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: radiotap discrepancy in Linux vs OpenBSD 2007-03-26 15:41 ` Luis R. Rodriguez @ 2007-03-26 16:59 ` David Young 0 siblings, 0 replies; 8+ messages in thread From: David Young @ 2007-03-26 16:59 UTC (permalink / raw) To: Luis R. Rodriguez; +Cc: Pavel Roskin, linux-wireless, Scott Raynel, radiotap On Mon, Mar 26, 2007 at 11:41:38AM -0400, Luis R. Rodriguez wrote: > CC'ing radiotap list, this time with your comments inline. > > On 3/25/07, David Young <dyoung@pobox.com> wrote: > >On Sun, Mar 25, 2007 at 11:24:16PM -0400, Pavel Roskin wrote: > >> Hello! > > > >(Oops, this time cc'd radiotap.) > > > >The place to discuss this is the mailing list > >radiotap@ojctech.com, which I have cc'd. Subscribe at > ><http://mail.ojctech.com/mailman/listinfo/radiotap>. Please feel free > >to circulate the URL. > > > >> I have noticed two different incompatible changes to enum > >> ieee80211_radiotap_type in ieee80211_radiotap.h. > >> > >> One is found in the current wireless-2.6.git: > >> > >> IEEE80211_RADIOTAP_RX_FLAGS = 14, > >> IEEE80211_RADIOTAP_TX_FLAGS = 15, > >> IEEE80211_RADIOTAP_RTS_RETRIES = 16, > >> IEEE80211_RADIOTAP_DATA_RETRIES = 17, > > > >These fields are slated to become part of the standard, I just haven't got > >around to updating the manual page, yet. I have time to do that tonight. > > > >> It was added together with Marvell Libertas USB driver. > > > >> Another set of the flags can be found in CVS OpenBSD: > >> > >> IEEE80211_RADIOTAP_FCS = 14, > >> IEEE80211_RADIOTAP_HWQUEUE = 15, > >> IEEE80211_RADIOTAP_RSSI = 16, > > > >These fields are not part of the standard, and they will not become part > >of the standard with these numbers. This is the first time I have ever > >heard of HWQUEUE and RSSI, actually. What are they for? > > RSSI is Received Signal Strength Indication. Its a measurement of the > received radio signal strength. Unfortunately though RSSI units used > are arbitrary and the maximum value differs amongst chipsets. From > wikipedia: > > -- > RSSI measurements will vary from 0 to 255 depending on the vendor. It > consists of a one byte integer value. A value of 1 will indicate the > minimum signal strength detectable by the wireless card, while 0 > indicates no signal. The value has a maximum of RSSI_Max. For example, > Cisco Systems cards will return a RSSI of 0 to 100. In this case, the > RSSI_Max is 100. The Cisco card can report 101 distinct power levels. > Another popular Wi-Fi chipset is made by Atheros. An Atheros based > card will return a RSSI value of 0 to 60. > -- > > As Samuel Barber had recommended before, we should probably instead > adopt RCPI. Quoting from his e-mail: RCPI sounds desirable. Let us avoid labeling a field RCPI if it isn't. We may need both fields, RSSI (defined: uncalibrated, unsigned, unitless signal strength, greater numbers -> greater strength) and RCPI (defined per 802.11k draft 5.0). Is 802.11k changing very rapidly, esp. the RCPI definition? Dave -- David Young OJC Technologies dyoung@ojctech.com Urbana, IL * (217) 278-3933 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-03-28 20:33 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-03-26 3:24 RFC: radiotap discrepancy in Linux vs OpenBSD Pavel Roskin 2007-03-26 3:37 ` David Young 2007-03-26 22:45 ` Pavel Roskin 2007-03-28 18:04 ` [Radiotap] " Marcelo Tosatti 2007-03-28 20:33 ` Pavel Roskin 2007-03-26 3:38 ` David Young 2007-03-26 15:41 ` Luis R. Rodriguez 2007-03-26 16:59 ` David Young
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).