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
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
On Sun, Mar 25, 2007 at 11:24:16PM -0400, Pavel Roskin wrote:
> Hello!
The place to discuss this is the mailing list
[email protected], 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
[email protected] Urbana, IL * (217) 278-3933
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 <[email protected]> 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
> >[email protected], 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
[email protected] Urbana, IL * (217) 278-3933
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.
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
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
[email protected], 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
[email protected] Urbana, IL * (217) 278-3933
CC'ing radiotap list, this time with your comments inline.
On 3/25/07, David Young <[email protected]> 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
> [email protected], 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.
--