ath9k returns a wrong RSSI value for frames received in a 30ms time
window after a channel change. The correct value is typically 10dB
below the returned value.
This was found with a Atheros AR9300 Rev:3 chip (WLE350NX / JWX6083
cards), during offchannel scans.
Mark the signal value as invalid in this case.
Signed-off-by: Jean Pierre TOSONI <[email protected]>
---
V2: replace LEDE patch with due kernel patch (with excuses to Kalle Valo)
drivers/net/wireless/ath/ath9k/ani.c | 1 +
drivers/net/wireless/ath/ath9k/common.c | 10 ++++++++++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ani.c b/drivers/net/wireless/at=
h/ath9k/ani.c
index 5214dd7..a7e07ed 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -317,6 +317,7 @@ void ath9k_ani_reset(struct ath_hw *ah, bool is_scannin=
g)
return;
=20
BUG_ON(aniState =3D=3D NULL);
+ ah->chan_stable_time =3D jiffies + (30*HZ)/1000; /* 30ms */
ah->stats.ast_ani_reset++;
=20
ofdm_nil =3D max_t(int, ATH9K_ANI_OFDM_DEF_LEVEL,
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless=
/ath/ath9k/common.c
index 099f3d4..7e5f7a3 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -221,6 +221,16 @@ void ath9k_cmn_process_rssi(struct ath_common *common,
int i, j;
=20
/*
+ * RSSI is not available before 30ms after reset on ath9k.
+ */
+ if (time_before(jiffies, ah->chan_stable_time)) {
+ ath_dbg(common, ANY, "early frame rssi=3D%d\n",rx_stats->rs_rssi);
+ rxs->flag |=3D RX_FLAG_NO_SIGNAL_VAL;
+ return;
+ }
+ ah->chan_stable_time =3D jiffies; /* advance stable time to cop with jiff=
ies wraparound */
+
+ /*
* RSSI is not available for subframes in an A-MPDU.
*/
if (rx_stats->rs_moreaggr) {
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath=
/ath9k/hw.h
index 9804a24..ec07da9 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -809,6 +809,7 @@ struct ath_hw {
=20
bool reset_power_on;
bool htc_reset_init;
+ unsigned long chan_stable_time;
=20
enum nl80211_iftype opmode;
enum ath9k_power_mode power_mode;
--=20
1.7.2.5
On Thu, Feb 15, 2018 at 07:51:28AM +0200, Kalle Valo wrote:
> James Cameron <[email protected]> writes:
>
> > On Wed, Feb 14, 2018 at 04:26:42PM +0000, Jean Pierre TOSONI wrote:
> >> ath9k returns a wrong RSSI value for frames received in a 30ms time
> >> window after a channel change. The correct value is typically 10dB
> >> below the returned value.
> >
> > How was your correct value determined?
> >
> >> This was found with a Atheros AR9300 Rev:3 chip (WLE350NX / JWX6083
> >> cards), during offchannel scans.
> >>
> >> Mark the signal value as invalid in this case.
> >
> > Why not adjust by 10dB?
> >
> > Speculating: in a typical card, RSSI is calculated by firmware from
> > readings of ADCs attached to the receiver. Firmware may average
> > several readings. Firmware may apply other offsets or calibrations,
> > based on frequency and temperature. This sounds like a firmware
> > problem.
>
> ath9k does not have firmware, only ath9k_htc has it.
Heh. s/firmware/silicon implementation/g
--
James Cameron
http://quozl.netrek.org/
On 2018-02-14 17:26, Jean Pierre TOSONI wrote:
> ath9k returns a wrong RSSI value for frames received in a 30ms time
> window after a channel change. The correct value is typically 10dB
> below the returned value.
>
> This was found with a Atheros AR9300 Rev:3 chip (WLE350NX / JWX6083
> cards), during offchannel scans.
>
> Mark the signal value as invalid in this case.
>
> Signed-off-by: Jean Pierre TOSONI <[email protected]>
It seems that this will potentially cause a lot of scan results with
RSSI information missing, which I think may be worse than a 10 db
fluctuation.
Actually, it could also be that the hardware is reporting accurate RSSI
values (they're reported as SNR relative to the noise floor) and this is
just a blip caused by the fact that the hw is updating its internal
noise floor value based on running measurements.
Does the same fluctuation also happen if you set update = false for
calls to ath9k_hw_start_nfcal?
- Felix
James Cameron <[email protected]> writes:
> On Wed, Feb 14, 2018 at 04:26:42PM +0000, Jean Pierre TOSONI wrote:
>> ath9k returns a wrong RSSI value for frames received in a 30ms time
>> window after a channel change. The correct value is typically 10dB
>> below the returned value.
>
> How was your correct value determined?
>
>> This was found with a Atheros AR9300 Rev:3 chip (WLE350NX / JWX6083
>> cards), during offchannel scans.
>>
>> Mark the signal value as invalid in this case.
>
> Why not adjust by 10dB?
>
> Speculating: in a typical card, RSSI is calculated by firmware from
> readings of ADCs attached to the receiver. Firmware may average
> several readings. Firmware may apply other offsets or calibrations,
> based on frequency and temperature. This sounds like a firmware
> problem.
ath9k does not have firmware, only ath9k_htc has it.
--
Kalle Valo
PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogc3RldmUuZGVyb3NpZXJAZ21h
aWwuY29tIFttYWlsdG86c3RldmUuZGVyb3NpZXJAZ21haWwuY29tXSBEZQ0KPiBsYSBwYXJ0IGRl
IFN0ZXZlIGRlUm9zaWVyDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTQgZsOpdnJpZXIgMjAxOCAx
OToxNg0KPiDDgMKgOiBKZWFuIFBpZXJyZSBUT1NPTkkNCj4gQ2PCoDogS2FsbGUgVmFsbzsgbGlu
dXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnOyBhdGg5ay0NCj4gZGV2ZWxAcWNhLnF1YWxjb21t
LmNvbQ0KPiBPYmpldMKgOiBSZTogW1BBVENIIHYyXSBhdGg5azogbWFyayBSU1NJIGFzIGludmFs
aWQgaWYgZnJhbWUgcmVjZWl2ZWQNCj4gZHVyaW5nIGNoYW5uZWwgc2V0dXANCj4gDQo+IE9uIFdl
ZCwgRmViIDE0LCAyMDE4IGF0IDg6MjYgQU0sIEplYW4gUGllcnJlIFRPU09OSQ0KPiA8anAudG9z
b25pQGFja3N5cy5mcj4gd3JvdGU6DQo+ID4gYXRoOWsgcmV0dXJucyBhIHdyb25nIFJTU0kgdmFs
dWUgZm9yIGZyYW1lcyByZWNlaXZlZCBpbiBhIDMwbXMNCj4gdGltZQ0KPiA+IHdpbmRvdyBhZnRl
ciBhIGNoYW5uZWwgY2hhbmdlLiBUaGUgY29ycmVjdCB2YWx1ZSBpcyB0eXBpY2FsbHkgMTBkQg0K
PiA+IGJlbG93IHRoZSByZXR1cm5lZCB2YWx1ZS4NCj4gPg0KPiA+IFRoaXMgd2FzIGZvdW5kIHdp
dGggYSBBdGhlcm9zIEFSOTMwMCBSZXY6MyBjaGlwIChXTEUzNTBOWCAvDQo+IEpXWDYwODMNCj4g
PiBjYXJkcyksIGR1cmluZyBvZmZjaGFubmVsIHNjYW5zLg0KPiA+DQo+IA0KPiBJcyB0aGlzIHRy
dWUgZm9yIEFMTCBhdGg5ayBjaGlwcyBvciBvbmx5IGZvciB0aGUgc3BlY2lmaWMgZGV2aWNlPyBJ
Zg0KPiBpdCdzIG5vdCBnZW5lcmFsbHkgdHJ1ZSwgd2Ugc2hvdWxkbid0IGJlIGFkZGluZyBjb2Rl
IHRoYXQgYXBwbGllcyB0bw0KPiBhbGwuIFBlcmhhcHMgYSBxdWlyayBvciBrZXllZCB0byBhIHNw
ZWNpZmljIGNoaXAgaWQgb3IgRFQgZW50cnkgb3INCj4gb3RoZXIgd2F5IHRvIGd1YXJkIGl0Pw0K
DQpZb3UgYXJlIHJpZ2h0Lg0KT24gbXkgaGFyZHdhcmUgSSBjb3VsZCBvbmx5IHRyeSB0aGVzZSB0
d28gUENJZSBjYXJkcyB3aGljaCB1c2UgdGhlIHNhbWUgY2hpcC4NCkJ1dCBJIGNhbm5vdCBiZSBz
dXJlIGl0IGFwcGxpZXMgdG8gb3RoZXIgYXRoOWsuIFNob3VsZCBJIGNoZWNrIHRoZSBQQ0kgcHJv
ZHVjdCBJRD8NCg0KPiANCj4gLSBTdGV2ZQ0K
PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRmVsaXggRmlldGthdSBbbWFp
bHRvOm5iZEBuYmQubmFtZV0NCj4gRW52b3nDqcKgOiBqZXVkaSAxNSBmw6l2cmllciAyMDE4IDE1
OjQ2DQo+IMOAwqA6IEplYW4gUGllcnJlIFRPU09OSTsgS2FsbGUgVmFsbw0KPiBDY8KgOiBsaW51
eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmc7IGF0aDlrLWRldmVsQHFjYS5xdWFsY29tbS5jb20N
Cj4gT2JqZXTCoDogUmU6IFtQQVRDSCB2Ml0gYXRoOWs6IG1hcmsgUlNTSSBhcyBpbnZhbGlkIGlm
IGZyYW1lIHJlY2VpdmVkDQo+IGR1cmluZyBjaGFubmVsIHNldHVwDQo+IA0KPiBPbiAyMDE4LTAy
LTE0IDE3OjI2LCBKZWFuIFBpZXJyZSBUT1NPTkkgd3JvdGU6DQo+ID4gYXRoOWsgcmV0dXJucyBh
IHdyb25nIFJTU0kgdmFsdWUgZm9yIGZyYW1lcyByZWNlaXZlZCBpbiBhIDMwbXMNCj4gdGltZQ0K
PiA+IHdpbmRvdyBhZnRlciBhIGNoYW5uZWwgY2hhbmdlLiBUaGUgY29ycmVjdCB2YWx1ZSBpcyB0
eXBpY2FsbHkgMTBkQg0KPiA+IGJlbG93IHRoZSByZXR1cm5lZCB2YWx1ZS4NCj4gPg0KPiA+IFRo
aXMgd2FzIGZvdW5kIHdpdGggYSBBdGhlcm9zIEFSOTMwMCBSZXY6MyBjaGlwIChXTEUzNTBOWCAv
DQo+IEpXWDYwODMNCj4gPiBjYXJkcyksIGR1cmluZyBvZmZjaGFubmVsIHNjYW5zLg0KPiA+DQo+
ID4gTWFyayB0aGUgc2lnbmFsIHZhbHVlIGFzIGludmFsaWQgaW4gdGhpcyBjYXNlLg0KPiA+DQo+
ID4gU2lnbmVkLW9mZi1ieTogSmVhbiBQaWVycmUgVE9TT05JIDxqcC50b3NvbmlAYWNrc3lzLmZy
Pg0KPiBJdCBzZWVtcyB0aGF0IHRoaXMgd2lsbCBwb3RlbnRpYWxseSBjYXVzZSBhIGxvdCBvZiBz
Y2FuIHJlc3VsdHMgd2l0aA0KPiBSU1NJIGluZm9ybWF0aW9uIG1pc3NpbmcsIHdoaWNoIEkgdGhp
bmsgbWF5IGJlIHdvcnNlIHRoYW4gYSAxMCBkYg0KPiBmbHVjdHVhdGlvbi4NCg0KSG1tbS4uLiBN
eSBjbGllbnQgaXMgbW92aW5nIGxpbmVhcmx5IGZyb20gQVAgdG8gQVAgYW5kIGlmIGl0IGZpbmRz
DQogdGhhdCB0aGUgcHJldmlvdXMgQVAgaXMgImJldHRlciIgdGhhbiB0aGUgY3VycmVudCBvciBu
ZXh0IG9uZSwNCiBoYXZvYyB3aWxsIG9jY3VyIG9uIHRocm91Z2hwdXQhIEluIHRoaXMgY2FzZSBJ
IHByZWZlciB0byB3YWl0IGZvcg0KIHRoZSBuZXh0IHNjYW4gcm91bmQgdGhhbiB1c2UgYSB3cm9u
ZyB2YWx1ZS4NCg0KQWxzbywgbm90ZSB0aGF0IG15IHBhdGNoIHNldHMgdGhlIGludmFsaWQgZmxh
ZyBidXQgaXQgaXMgY3VycmVudGx5DQogSWdub3JlZCBieSBtYWM4MDIxMSAoSSBzdWJtaXR0ZWQg
YW5vdGhlciBwYXRjaCBhYm91dCB0aGF0KS4NCg0KQWN0dWFsbHkgdGhlIHByb2JsZW0gc2hvd3Mg
dXAgb25seSBvbiBwYXNzaXZlIGNoYW5uZWxzLCBiZWNhdXNlDQooMSkgb24gYWN0aXZlIGNoYW5u
ZWxzIHRoZSB3cm9uZyBiZWFjb24gcmVwb3J0IHdpbGwgYmUgc29vbg0KICAgIG92ZXJ3cml0dGVu
IGJ5IHRoZSBwcm9iZSByZXNwb25zZSByZXBvcnQNCigyKSBtYWM4MDIxMSB3YWl0cyBvbmx5IGZv
ciAxMDhtcyBvbiBwYXNzaXZlIGNoYW5uZWxzLCBpZiBpdCB3YWl0ZWQNCiAgICBmb3IgMTMzbXMg
d2Ugd291bGQgaGF2ZSB0aGUgb3Bwb3J0dW5pdHkgdG8gb2J0YWluIGEgMm5kIGNvcnJlY3QNCiAg
ICBiZWFjb24gcmVwb3J0ICh3ZWxsLCBkZXBlbmRpbmcgb24gdGhlIGJlYWNvbiBpbnRlcnZhbCBv
ZiBjb3Vyc2UpDQoNCj4gQWN0dWFsbHksIGl0IGNvdWxkIGFsc28gYmUgdGhhdCB0aGUgaGFyZHdh
cmUgaXMgcmVwb3J0aW5nIGFjY3VyYXRlDQo+IFJTU0kgdmFsdWVzICh0aGV5J3JlIHJlcG9ydGVk
IGFzIFNOUiByZWxhdGl2ZSB0byB0aGUgbm9pc2UgZmxvb3IpDQo+IGFuZCB0aGlzIGlzIGp1c3Qg
YSBibGlwIGNhdXNlZCBieSB0aGUgZmFjdCB0aGF0IHRoZSBodyBpcyB1cGRhdGluZw0KPiBpdHMg
aW50ZXJuYWwgbm9pc2UgZmxvb3IgdmFsdWUgYmFzZWQgb24gcnVubmluZyBtZWFzdXJlbWVudHMu
DQo+IA0KPiBEb2VzIHRoZSBzYW1lIGZsdWN0dWF0aW9uIGFsc28gaGFwcGVuIGlmIHlvdSBzZXQg
dXBkYXRlID0gZmFsc2UgZm9yDQo+IGNhbGxzIHRvIGF0aDlrX2h3X3N0YXJ0X25mY2FsPw0KDQpU
aGFua3MgZm9yIHRoZSBoaW50LCBJIHdpbGwgaGF2ZSBhIGxvb2sgYXQgdGhhdCANCg0KPiANCj4g
LSBGZWxpeA0K
> -----Message d'origine-----
> De=A0: [email protected] [mailto:[email protected]]
> Envoy=E9=A0: jeudi 15 f=E9vrier 2018 08:21
> =C0=A0: Kalle Valo
> Cc=A0: Jean Pierre TOSONI; [email protected]; ath9k-
> [email protected]
> Objet=A0: Re: [PATCH v2] ath9k: mark RSSI as invalid if frame received
> during channel setup
>=20
> On Thu, Feb 15, 2018 at 07:51:28AM +0200, Kalle Valo wrote:
> > James Cameron <[email protected]> writes:
> >
> >> On Wed, Feb 14, 2018 at 04:26:42PM +0000, Jean Pierre TOSONI
> wrote:
> >>> ath9k returns a wrong RSSI value for frames received
> >>> in a 30ms time window after a channel change. The
> >>> correct value is typically 10dB below the returned value.
> >>
> >> How was your correct value determined?
> >>
1) test setup:
Connecting the AP through coax and attenuators, then making 500 passive sca=
ns off-channel, then drawing an histogram of the beacon signals found by th=
e chip. The off-channel period is 108 ms. The probability of being in the 3=
0 ms window is 28%. The histogram shows 2 spikes, one large with the expect=
ed value, one small at around +10dB above.
2) value determination
Adjust the delay (CONFIG_HZ=3D250) by trial and error. 25ms was not enough =
to completely absorb the +10dB spike in the histogram, while 30ms was enoug=
h.
Do you think of a better approach? Maybe the guys at Qualcomm know the corr=
ect value?=20
> >>> This was found with a Atheros AR9300 Rev:3 chip (WLE350NX /
> >>> JWX6083 cards), during offchannel scans.
> >>>
> >>> Mark the signal value as invalid in this case.
> >>
> >> Why not adjust by 10dB?
I considered that also. But,=20
1) during how much time should I do this adjustment? Around 30 ms after cha=
nnel switch?
2) The histogram shows a scattering of the measures in a +/- 3dB range arou=
nd the mean value.
So I could not decide for sure if it needed -9dB, -10dB or -11dB?
> >>
> >> Speculating: in a typical card, RSSI is calculated by firmware
> from
> >> readings of ADCs attached to the receiver. Firmware may average
> >> several readings. Firmware may apply other offsets or
> calibrations,
> >> based on frequency and temperature. This sounds like a firmware
> >> problem.
> >
> > ath9k does not have firmware, only ath9k_htc has it.
>=20
> Heh. s/firmware/silicon implementation/g
Oh well, if it's silicon problem, then it's a hardware problem, and
I am right to correct it that way, since there is no other way :-)
>=20
> --
> James Cameron
> http://quozl.netrek.org/
On Wed, Feb 14, 2018 at 8:26 AM, Jean Pierre TOSONI <[email protected]> wrote:
> ath9k returns a wrong RSSI value for frames received in a 30ms time
> window after a channel change. The correct value is typically 10dB
> below the returned value.
>
> This was found with a Atheros AR9300 Rev:3 chip (WLE350NX / JWX6083
> cards), during offchannel scans.
>
Is this true for ALL ath9k chips or only for the specific device? If
it's not generally true, we shouldn't be adding code that applies to
all. Perhaps a quirk or keyed to a specific chip id or DT entry or
other way to guard it?
- Steve
On Thu, Feb 15, 2018 at 08:52:53AM +0000, Jean Pierre TOSONI wrote:
> > -----Message d'origine-----
> > De?: [email protected] [mailto:[email protected]]
> > Envoy??: jeudi 15 f?vrier 2018 08:21
> > ??: Kalle Valo
> > Cc?: Jean Pierre TOSONI; [email protected]; ath9k-
> > [email protected]
> > Objet?: Re: [PATCH v2] ath9k: mark RSSI as invalid if frame received
> > during channel setup
> >
> > On Thu, Feb 15, 2018 at 07:51:28AM +0200, Kalle Valo wrote:
> > > James Cameron <[email protected]> writes:
> > >
> > >> On Wed, Feb 14, 2018 at 04:26:42PM +0000, Jean Pierre TOSONI
> > wrote:
> > >>> ath9k returns a wrong RSSI value for frames received
> > >>> in a 30ms time window after a channel change. The
> > >>> correct value is typically 10dB below the returned value.
> > >>
> > >> How was your correct value determined?
> > >>
>
> 1) test setup:
> Connecting the AP through coax and attenuators, then making 500 passive scans off-channel, then drawing an histogram of the beacon signals found by the chip. The off-channel period is 108 ms. The probability of being in the 30 ms window is 28%. The histogram shows 2 spikes, one large with the expected value, one small at around +10dB above.
>
> 2) value determination
> Adjust the delay (CONFIG_HZ=250) by trial and error. 25ms was not enough to completely absorb the +10dB spike in the histogram, while 30ms was enough.
>
> Do you think of a better approach?
No, I think your approach is fine. I was curious. Thanks for explaining.
> Maybe the guys at Qualcomm know the correct value?
Yes, that seems likely.
> > >>> This was found with a Atheros AR9300 Rev:3 chip (WLE350NX /
> > >>> JWX6083 cards), during offchannel scans.
> > >>>
> > >>> Mark the signal value as invalid in this case.
> > >>
> > >> Why not adjust by 10dB?
>
> I considered that also. But,
> 1) during how much time should I do this adjustment? Around 30 ms after channel switch?
Yes. If RSSI is so critical for your application, you'll do what you
can to get a real RSSI rather than drop it.
> 2) The histogram shows a scattering of the measures in a +/- 3dB range around the mean value.
Perhaps a sampling error by the device.
> So I could not decide for sure if it needed -9dB, -10dB or -11dB?
>
> > >>
> > >> Speculating: in a typical card, RSSI is calculated by firmware
> > from
> > >> readings of ADCs attached to the receiver. Firmware may average
> > >> several readings. Firmware may apply other offsets or
> > calibrations,
> > >> based on frequency and temperature. This sounds like a firmware
> > >> problem.
> > >
> > > ath9k does not have firmware, only ath9k_htc has it.
> >
> > Heh. s/firmware/silicon implementation/g
>
> Oh well, if it's silicon problem, then it's a hardware problem, and
> I am right to correct it that way, since there is no other way :-)
Yes, if it can be reproduced by every ath9k.
--
James Cameron
http://quozl.netrek.org/
On Wed, Feb 14, 2018 at 04:26:42PM +0000, Jean Pierre TOSONI wrote:
> ath9k returns a wrong RSSI value for frames received in a 30ms time
> window after a channel change. The correct value is typically 10dB
> below the returned value.
How was your correct value determined?
> This was found with a Atheros AR9300 Rev:3 chip (WLE350NX / JWX6083
> cards), during offchannel scans.
>
> Mark the signal value as invalid in this case.
Why not adjust by 10dB?
Speculating: in a typical card, RSSI is calculated by firmware from
readings of ADCs attached to the receiver. Firmware may average
several readings. Firmware may apply other offsets or calibrations,
based on frequency and temperature. This sounds like a firmware
problem.
> Signed-off-by: Jean Pierre TOSONI <[email protected]>
> [...]
--
James Cameron
http://quozl.netrek.org/