2018-02-08 09:49:31

by Jean-Pierre TOSONI

[permalink] [raw]
Subject: mac80211 scan results, signal value not reliable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D----------=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-----=
-----=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D----------=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Hello list,

In net/mac80211/scan.c, function ieee80211_bss_info_update() passes
incoming scan results to the generic wireless layer, with indication of
the received signal level, but no indication of signal validity.

Before ieee80211_bss_info_update() is called, rx_status->flag can be set
to RX_FLAG_NO_SIGNAL_VAL by the ath9k driver and it won't be taken into
account in the wireless layer.
Even later in ieee80211_bss_info_update(), rx_status->flag can also be set
to RX_FLAG_NO_SIGNAL_VAL, and the wireless layer won't be aware of this.

I stumbled on this because, when using ath9k (WLE350NX) to do a passive sca=
n
off-channel, the beacons received in a 30ms window after channel change sho=
w
a signal level +10dB above the real value. So I was looking for a way to
tell the above layers that the signal is invalid. RX_FLAG_NO_SIGNAL_VAL see=
ms
to fit, but is not conveyed up to iw or wpa_supplicant.

In fact I did not find any such thing in net/wireless/nl80211.c, function
nl80211_send_bss().

Any suggestion? Did I miss something?

Regards,
Jean-Pierre


2018-02-14 10:46:29

by Johannes Berg

[permalink] [raw]
Subject: Re: mac80211 scan results, signal value not reliable

On Wed, 2018-02-14 at 10:10 +0000, Jean Pierre TOSONI wrote:
> >
> > However, it looks like you're right and ieee80211_bss_info_update()
> > doesn't take the flag into account. Bit strange that we even have
> > the flag I guess, since we treat 0 as an invalid value in various
> > places, being too high power to realistically receive anyway.
>
> The problem is that 0 is invalid as a SIGNAL_DBM value but this is
> dubious for a SIGNAL_UNSPEC value which appears to be still in use
> in a couple of drivers.

Huh, good point, that's ancient history to me and I forget :-)

> > Want to send a patch? There seem to be a few more places as well,
>
> I am working on a 3.18 kernel; so I can either make the patch from
> an old compat-wireless, or make the patch from your last tree but
> I cannot test it; are you interested anyways?

The only useful patch would be on the last tree. :-)

> > e.g.
> > in rx.c for cfg80211_report_obss_beacon() and cfg80211_rx_mgmt().
>
> There is also mlme.c, the ifmgd->ave_beacon_signal should not be updated
> with an invalid signal;
> and in the last tree, the ibss join passes an uninitialized signal
> value to cfg80211_inform_bss_frame_data().

Good catch!

johannes

2018-02-10 21:09:15

by Johannes Berg

[permalink] [raw]
Subject: Re: mac80211 scan results, signal value not reliable

On Thu, 2018-02-08 at 09:49 +0000, Jean Pierre TOSONI wrote:

> In net/mac80211/scan.c, function ieee80211_bss_info_update() passes
> incoming scan results to the generic wireless layer, with indication of
> the received signal level, but no indication of signal validity.

Well, there is an indication of validity, if the value is 0 then it's
invalid.

> Before ieee80211_bss_info_update() is called, rx_status->flag can be set
> to RX_FLAG_NO_SIGNAL_VAL by the ath9k driver and it won't be taken into
> account in the wireless layer.
> Even later in ieee80211_bss_info_update(), rx_status->flag can also be set
> to RX_FLAG_NO_SIGNAL_VAL, and the wireless layer won't be aware of this.

However, it looks like you're right and ieee80211_bss_info_update()
doesn't take the flag into account. Bit strange that we even have the
flag I guess, since we treat 0 as an invalid value in various places,
being too high power to realistically receive anyway.

> I stumbled on this because, when using ath9k (WLE350NX) to do a passive scan
> off-channel, the beacons received in a 30ms window after channel change show
> a signal level +10dB above the real value. So I was looking for a way to
> tell the above layers that the signal is invalid. RX_FLAG_NO_SIGNAL_VAL seems
> to fit, but is not conveyed up to iw or wpa_supplicant.
>
> In fact I did not find any such thing in net/wireless/nl80211.c, function
> nl80211_send_bss().
>
> Any suggestion? Did I miss something?

Want to send a patch? There seem to be a few more places as well, e.g.
in rx.c for cfg80211_report_obss_beacon() and cfg80211_rx_mgmt().

johannes

2018-02-14 10:10:51

by Jean-Pierre TOSONI

[permalink] [raw]
Subject: RE: mac80211 scan results, signal value not reliable

DQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBKb2hhbm5lcyBCZXJnIFtt
YWlsdG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0NCj4gRW52b3nDqcKgOiBzYW1lZGkgMTAg
ZsOpdnJpZXIgMjAxOCAyMjowOQ0KPiDDgMKgOiBKZWFuIFBpZXJyZSBUT1NPTkk7IGxpbnV4LXdp
cmVsZXNzQHZnZXIua2VybmVsLm9yZw0KPiBPYmpldMKgOiBSZTogbWFjODAyMTEgc2NhbiByZXN1
bHRzLCBzaWduYWwgdmFsdWUgbm90IHJlbGlhYmxlDQo+IA0KPiBPbiBUaHUsIDIwMTgtMDItMDgg
YXQgMDk6NDkgKzAwMDAsIEplYW4gUGllcnJlIFRPU09OSSB3cm90ZToNCj4gDQo+ID4gSW4gbmV0
L21hYzgwMjExL3NjYW4uYywgZnVuY3Rpb24gaWVlZTgwMjExX2Jzc19pbmZvX3VwZGF0ZSgpDQo+
IHBhc3Nlcw0KPiA+IGluY29taW5nIHNjYW4gcmVzdWx0cyB0byB0aGUgZ2VuZXJpYyB3aXJlbGVz
cyBsYXllciwgd2l0aA0KPiBpbmRpY2F0aW9uDQo+ID4gb2YgdGhlIHJlY2VpdmVkIHNpZ25hbCBs
ZXZlbCwgYnV0IG5vIGluZGljYXRpb24gb2Ygc2lnbmFsDQo+IHZhbGlkaXR5Lg0KPiANCj4gV2Vs
bCwgdGhlcmUgaXMgYW4gaW5kaWNhdGlvbiBvZiB2YWxpZGl0eSwgaWYgdGhlIHZhbHVlIGlzIDAg
dGhlbg0KPiBpdCdzIGludmFsaWQuDQo+IA0KPiA+IEJlZm9yZSBpZWVlODAyMTFfYnNzX2luZm9f
dXBkYXRlKCkgaXMgY2FsbGVkLCByeF9zdGF0dXMtPmZsYWcgY2FuDQo+IGJlDQo+ID4gc2V0IHRv
IFJYX0ZMQUdfTk9fU0lHTkFMX1ZBTCBieSB0aGUgYXRoOWsgZHJpdmVyIGFuZCBpdCB3b24ndCBi
ZQ0KPiB0YWtlbg0KPiA+IGludG8gYWNjb3VudCBpbiB0aGUgd2lyZWxlc3MgbGF5ZXIuDQo+ID4g
RXZlbiBsYXRlciBpbiBpZWVlODAyMTFfYnNzX2luZm9fdXBkYXRlKCksIHJ4X3N0YXR1cy0+Zmxh
ZyBjYW4NCj4gYWxzbyBiZQ0KPiA+IHNldCB0byBSWF9GTEFHX05PX1NJR05BTF9WQUwsIGFuZCB0
aGUgd2lyZWxlc3MgbGF5ZXIgd29uJ3QgYmUNCj4gYXdhcmUgb2YgdGhpcy4NCj4gDQo+IEhvd2V2
ZXIsIGl0IGxvb2tzIGxpa2UgeW91J3JlIHJpZ2h0IGFuZCBpZWVlODAyMTFfYnNzX2luZm9fdXBk
YXRlKCkNCj4gZG9lc24ndCB0YWtlIHRoZSBmbGFnIGludG8gYWNjb3VudC4gQml0IHN0cmFuZ2Ug
dGhhdCB3ZSBldmVuIGhhdmUNCj4gdGhlIGZsYWcgSSBndWVzcywgc2luY2Ugd2UgdHJlYXQgMCBh
cyBhbiBpbnZhbGlkIHZhbHVlIGluIHZhcmlvdXMNCj4gcGxhY2VzLCBiZWluZyB0b28gaGlnaCBw
b3dlciB0byByZWFsaXN0aWNhbGx5IHJlY2VpdmUgYW55d2F5Lg0KDQpUaGUgcHJvYmxlbSBpcyB0
aGF0IDAgaXMgaW52YWxpZCBhcyBhIFNJR05BTF9EQk0gdmFsdWUgYnV0IHRoaXMgaXMNCmR1Ymlv
dXMgZm9yIGEgU0lHTkFMX1VOU1BFQyB2YWx1ZSB3aGljaCBhcHBlYXJzIHRvIGJlIHN0aWxsIGlu
IHVzZQ0KaW4gYSBjb3VwbGUgb2YgZHJpdmVycy4NCg0KU3VyZSB0aGF0IHVzaW5nIDAgd2lsbCBz
b2x2ZSBteSBvd24gcHJvYmxlbS4NCg0KPiANCj4gPiBJIHN0dW1ibGVkIG9uIHRoaXMgYmVjYXVz
ZSwgd2hlbiB1c2luZyBhdGg5ayAoV0xFMzUwTlgpIHRvIGRvIGENCj4gPiBwYXNzaXZlIHNjYW4g
b2ZmLWNoYW5uZWwsIHRoZSBiZWFjb25zIHJlY2VpdmVkIGluIGEgMzBtcyB3aW5kb3cNCj4gYWZ0
ZXINCj4gPiBjaGFubmVsIGNoYW5nZSBzaG93IGEgc2lnbmFsIGxldmVsICsxMGRCIGFib3ZlIHRo
ZSByZWFsIHZhbHVlLiBTbw0KPiBJDQo+ID4gd2FzIGxvb2tpbmcgZm9yIGEgd2F5IHRvIHRlbGwg
dGhlIGFib3ZlIGxheWVycyB0aGF0IHRoZSBzaWduYWwgaXMNCj4gPiBpbnZhbGlkLiBSWF9GTEFH
X05PX1NJR05BTF9WQUwgc2VlbXMgdG8gZml0LCBidXQgaXMgbm90IGNvbnZleWVkDQo+IHVwIHRv
IGl3IG9yIHdwYV9zdXBwbGljYW50Lg0KPiA+DQo+ID4gSW4gZmFjdCBJIGRpZCBub3QgZmluZCBh
bnkgc3VjaCB0aGluZyBpbiBuZXQvd2lyZWxlc3Mvbmw4MDIxMS5jLA0KPiA+IGZ1bmN0aW9uIG5s
ODAyMTFfc2VuZF9ic3MoKS4NCj4gPg0KPiA+IEFueSBzdWdnZXN0aW9uPyBEaWQgSSBtaXNzIHNv
bWV0aGluZz8NCj4gDQo+IFdhbnQgdG8gc2VuZCBhIHBhdGNoPyBUaGVyZSBzZWVtIHRvIGJlIGEg
ZmV3IG1vcmUgcGxhY2VzIGFzIHdlbGwsDQoNCkkgYW0gd29ya2luZyBvbiBhIDMuMTgga2VybmVs
OyBzbyBJIGNhbiBlaXRoZXIgbWFrZSB0aGUgcGF0Y2ggZnJvbQ0KYW4gb2xkIGNvbXBhdC13aXJl
bGVzcywgb3IgbWFrZSB0aGUgcGF0Y2ggZnJvbSB5b3VyIGxhc3QgdHJlZSBidXQNCkkgY2Fubm90
IHRlc3QgaXQ7IGFyZSB5b3UgaW50ZXJlc3RlZCBhbnl3YXlzPw0KDQo+IGUuZy4NCj4gaW4gcngu
YyBmb3IgY2ZnODAyMTFfcmVwb3J0X29ic3NfYmVhY29uKCkgYW5kIGNmZzgwMjExX3J4X21nbXQo
KS4NCg0KVGhlcmUgaXMgYWxzbyBtbG1lLmMsIHRoZSBpZm1nZC0+YXZlX2JlYWNvbl9zaWduYWwg
c2hvdWxkIG5vdCBiZSB1cGRhdGVkDQp3aXRoIGFuIGludmFsaWQgc2lnbmFsOw0KYW5kIGluIHRo
ZSBsYXN0IHRyZWUsIHRoZSBpYnNzIGpvaW4gcGFzc2VzIGFuIHVuaW5pdGlhbGl6ZWQgc2lnbmFs
DQp2YWx1ZSB0byBjZmc4MDIxMV9pbmZvcm1fYnNzX2ZyYW1lX2RhdGEoKS4NCg0KPiANCj4gam9o
YW5uZXMNCg==