Incorrect signal levels reported using wpa_supplicant's driver_nl80211

Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Maxim Levitsky]

Sorry for cross-posting, but this issue really spans all three systems.

I anylized why I get 100% quality on all access points except currently
connected, when I used driver_nl80211 of wpa_supplcant.

First, when NetworkManager plans to switch to this driver?
For me it gives me faster association speeds, especially when I toggle
wireless with rfkill button.


this is what happens on the kernel side:
--> n80211 encodes only dBm data. It does so in, nl80211_send_bss.
	(or it can encode unspecified data, which has little use...)

--> kernel also gives maximum ranges in, cfg80211_wext_giwrange, which is used by NM:
	range->max_qual.updated = IW_QUAL_NOISE_INVALID | IW_QUAL_DBM | IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED ;
	range->max_qual.level = -110;
	range->max_qual.qual = 70;
Thus it reports that it can't report noise.


driver_nl80211 side:

--> sends data as is, done in bss_info_handler:
	r->level = nla_get_u32(bss[NL80211_BSS_SIGNAL_MBM]);
	r->level /= 100; /* mBm to dBm */
	r->flags |= WPA_SCAN_LEVEL_DBM | WPA_SCAN_QUAL_INVALID;

Again explicitly says that has no quality data, sends only dBm or unspecified data;



NM side:

--> three strategies used (in wireless_qual_to_percent)
	--> quality: (used with driver_wext), not reported by nl80211

	--> dbm: used only if:
		* valid and zero max_qual->level (but now set to -110....) 
		* valid level (OK)
		* valid positive max_qual->noise OR valid positive current noise (noise set to invalid and not reported even by my driver...)

	--> RSSI: (device reports numbers from 0 to max_qual.level):
		* nonzero valid max_qual->level, and it is assumed to be positive too...
		* valid level
		

currently RSSI path is taken and results in 100% quality.


I think that dBm strategy should be revised, and in addtion to that.

Of course whole NM currently depends on WEXT, for exmple it would get signal level for current AP via WEXT, and thus use quality level
as reported by driver. 

Thus there are differences between NM dBm quality calculation and driver ones, and therefore NM will report different quality levels... sigh...


Best regards,
	Maxim Levitsky


PS: I want signal quality bars back in NM....

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Dan Williams]

On Sat, 2009-10-31 at 03:50 +0200, Maxim Levitsky wrote:
> Sorry for cross-posting, but this issue really spans all three systems.
> 
> I anylized why I get 100% quality on all access points except currently
> connected, when I used driver_nl80211 of wpa_supplcant.
> 
> First, when NetworkManager plans to switch to this driver?

Soon.  We've got some patches for this, but we'll also need tons of
testing.  The WEXT stuff is pretty baked while nl80211 is still under
some flux.  But of course the only way we bake nl80211 is by switching
to it...

> For me it gives me faster association speeds, especially when I toggle
> wireless with rfkill button.
> 
> 
> this is what happens on the kernel side:
> --> n80211 encodes only dBm data. It does so in, nl80211_send_bss.
> 	(or it can encode unspecified data, which has little use...)
> 
> --> kernel also gives maximum ranges in, cfg80211_wext_giwrange, which is used by NM:
> 	range->max_qual.updated = IW_QUAL_NOISE_INVALID | IW_QUAL_DBM | IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED ;
> 	range->max_qual.level = -110;
> 	range->max_qual.qual = 70;
> Thus it reports that it can't report noise.
> 
> 
> driver_nl80211 side:
> 
> --> sends data as is, done in bss_info_handler:
> 	r->level = nla_get_u32(bss[NL80211_BSS_SIGNAL_MBM]);
> 	r->level /= 100; /* mBm to dBm */
> 	r->flags |= WPA_SCAN_LEVEL_DBM | WPA_SCAN_QUAL_INVALID;
> 
> Again explicitly says that has no quality data, sends only dBm or unspecified data;
> 
> 
> 
> NM side:
> 
> --> three strategies used (in wireless_qual_to_percent)
> 	--> quality: (used with driver_wext), not reported by nl80211
> 
> 	--> dbm: used only if:
> 		* valid and zero max_qual->level (but now set to -110....) 

IIRC non-zero max_qual->level was the indication that the driver wanted
to use RSSI, not dBm.  Since the real "max" dBm is around 0 (ie, that's
the highest signal strength you'll ever really see), max_qual->level
meant the driver was reporting signal strength in dBm.  max_qual->level
== -110 is kinda wrong, because that's the _minimum_ level, not the max.
The noise floor is almost always around -100 dBm so setting
max_qual->level is pretty useless.

This is *exactly* why 'qual' is there: so that the driver itself can
figure out what the hell it's signal level is, and so that NM doesn't
have to go around assuming stuff.

For WEXT reporting, mac80211 should really be constructing a 'qual'
instead of leaving it 0.  Then we don't have ambiguities with dBm, RSSI,
unspec, etc.

Dan

> 		* valid level (OK)
> 		* valid positive max_qual->noise OR valid positive current noise (noise set to invalid and not reported even by my driver...)
> 
> 	--> RSSI: (device reports numbers from 0 to max_qual.level):
> 		* nonzero valid max_qual->level, and it is assumed to be positive too...
> 		* valid level
> 		
> 
> currently RSSI path is taken and results in 100% quality.
> 
> 
> I think that dBm strategy should be revised, and in addtion to that.
> 
> Of course whole NM currently depends on WEXT, for exmple it would get signal level for current AP via WEXT, and thus use quality level
> as reported by driver. 
> 
> Thus there are differences between NM dBm quality calculation and driver ones, and therefore NM will report different quality levels... sigh...
> 
> 
> Best regards,
> 	Maxim Levitsky
> 
> 
> PS: I want signal quality bars back in NM....
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Maxim Levitsky]

On Mon, 2009-11-02 at 11:40 -0800, Dan Williams wrote: 
> On Sat, 2009-10-31 at 03:50 +0200, Maxim Levitsky wrote:
> > Sorry for cross-posting, but this issue really spans all three systems.
> > 
> > I anylized why I get 100% quality on all access points except currently
> > connected, when I used driver_nl80211 of wpa_supplcant.
> > 
> > First, when NetworkManager plans to switch to this driver?
> 
> Soon.  We've got some patches for this, but we'll also need tons of
> testing.  The WEXT stuff is pretty baked while nl80211 is still under
> some flux.  But of course the only way we bake nl80211 is by switching
> to it...
Glad to hear that!

I use driver_nl80211 and I have 3 problems.

1 - noise levels, this what I reported here.
2 - problems with wpa_supplicant that does no deauth on disconnect,
this can be easily worked around in supplicant code, but I feel some
disagreement between kernel and wpa_supplicant developers.

3 - seems that ibss is broken (even with all recently posted patches on
linux-wireless, wpa_supplicant still hangs while it attempts to create
the network. In fact I only tested creation of the network, not if
anybody could join it.


Speaking of joing the IBSS, NM did forever support the WPA encryption,
however, its isn't set in the beacon that is broadcast (in fact I only
see probe requests, not real beacons...)
Thus any attempt to join such network results in NM asking for wep keys.

It would be very nice to have WPA/2 IBSS, as this is the only real
encryption possible.


> 
> > For me it gives me faster association speeds, especially when I toggle
> > wireless with rfkill button.
> > 
> > 
> > this is what happens on the kernel side:
> > --> n80211 encodes only dBm data. It does so in, nl80211_send_bss.
> > 	(or it can encode unspecified data, which has little use...)
> > 
> > --> kernel also gives maximum ranges in, cfg80211_wext_giwrange, which is used by NM:
> > 	range->max_qual.updated = IW_QUAL_NOISE_INVALID | IW_QUAL_DBM | IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED ;
> > 	range->max_qual.level = -110;
> > 	range->max_qual.qual = 70;
> > Thus it reports that it can't report noise.
> > 
> > 
> > driver_nl80211 side:
> > 
> > --> sends data as is, done in bss_info_handler:
> > 	r->level = nla_get_u32(bss[NL80211_BSS_SIGNAL_MBM]);
> > 	r->level /= 100; /* mBm to dBm */
> > 	r->flags |= WPA_SCAN_LEVEL_DBM | WPA_SCAN_QUAL_INVALID;
> > 
> > Again explicitly says that has no quality data, sends only dBm or unspecified data;
> > 
> > 
> > 
> > NM side:
> > 
> > --> three strategies used (in wireless_qual_to_percent)
> > 	--> quality: (used with driver_wext), not reported by nl80211
> > 
> > 	--> dbm: used only if:
> > 		* valid and zero max_qual->level (but now set to -110....) 
> 
> IIRC non-zero max_qual->level was the indication that the driver wanted
> to use RSSI, not dBm.  Since the real "max" dBm is around 0 (ie, that's
> the highest signal strength you'll ever really see), max_qual->level
> meant the driver was reporting signal strength in dBm.  max_qual->level
> == -110 is kinda wrong, because that's the _minimum_ level, not the max.
This is very good point, a question for kernel developers, why it was
set as such? How about setting it to ?


> The noise floor is almost always around -100 dBm so setting
> max_qual->level is pretty useless.
> 
> This is *exactly* why 'qual' is there: so that the driver itself can
> figure out what the hell it's signal level is, and so that NM doesn't
> have to go around assuming stuff.
It appears as kernel developers want to drop quality calculations
altogether, and report everything in dBms (right?) 
This is also a consistent I think.

> 
> For WEXT reporting, mac80211 should really be constructing a 'qual'
> instead of leaving it 0.  Then we don't have ambiguities with dBm, RSSI,
> unspec, etc.
It does, but driver_nl80211 doesn't use wext that is.


Also a recent conversation on linux-wireless indicated that noise level
is a property of the wireless card, so I think we won't see them in scan
results any time soon.


Best regards,
Maxim Levitsky

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Dan Williams]

On Tue, 2009-11-03 at 01:07 +0200, Maxim Levitsky wrote:
> On Mon, 2009-11-02 at 11:40 -0800, Dan Williams wrote: 
> > On Sat, 2009-10-31 at 03:50 +0200, Maxim Levitsky wrote:
> > > Sorry for cross-posting, but this issue really spans all three systems.
> > > 
> > > I anylized why I get 100% quality on all access points except currently
> > > connected, when I used driver_nl80211 of wpa_supplcant.
> > > 
> > > First, when NetworkManager plans to switch to this driver?
> > 
> > Soon.  We've got some patches for this, but we'll also need tons of
> > testing.  The WEXT stuff is pretty baked while nl80211 is still under
> > some flux.  But of course the only way we bake nl80211 is by switching
> > to it...
> Glad to hear that!
> 
> I use driver_nl80211 and I have 3 problems.
> 
> 1 - noise levels, this what I reported here.
> 2 - problems with wpa_supplicant that does no deauth on disconnect,
> this can be easily worked around in supplicant code, but I feel some
> disagreement between kernel and wpa_supplicant developers.
> 
> 3 - seems that ibss is broken (even with all recently posted patches on
> linux-wireless, wpa_supplicant still hangs while it attempts to create
> the network. In fact I only tested creation of the network, not if
> anybody could join it.
> 
> 
> Speaking of joing the IBSS, NM did forever support the WPA encryption,
> however, its isn't set in the beacon that is broadcast (in fact I only
> see probe requests, not real beacons...)
> Thus any attempt to join such network results in NM asking for wep keys.

That's a mac80211/supplicant problem, I believe.  NM just sends the
config to the supplicant, and given that config, it's the supplicant and
driver's problem to set up the right network.  You can see the config
that NM sends in /var/log/messages or /var/log/daemon.log, wherever your
distro directs the 'daemon' syslog facility.

Dan

> It would be very nice to have WPA/2 IBSS, as this is the only real
> encryption possible.
> 
> 
> > 
> > > For me it gives me faster association speeds, especially when I toggle
> > > wireless with rfkill button.
> > > 
> > > 
> > > this is what happens on the kernel side:
> > > --> n80211 encodes only dBm data. It does so in, nl80211_send_bss.
> > > 	(or it can encode unspecified data, which has little use...)
> > > 
> > > --> kernel also gives maximum ranges in, cfg80211_wext_giwrange, which is used by NM:
> > > 	range->max_qual.updated = IW_QUAL_NOISE_INVALID | IW_QUAL_DBM | IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED ;
> > > 	range->max_qual.level = -110;
> > > 	range->max_qual.qual = 70;
> > > Thus it reports that it can't report noise.
> > > 
> > > 
> > > driver_nl80211 side:
> > > 
> > > --> sends data as is, done in bss_info_handler:
> > > 	r->level = nla_get_u32(bss[NL80211_BSS_SIGNAL_MBM]);
> > > 	r->level /= 100; /* mBm to dBm */
> > > 	r->flags |= WPA_SCAN_LEVEL_DBM | WPA_SCAN_QUAL_INVALID;
> > > 
> > > Again explicitly says that has no quality data, sends only dBm or unspecified data;
> > > 
> > > 
> > > 
> > > NM side:
> > > 
> > > --> three strategies used (in wireless_qual_to_percent)
> > > 	--> quality: (used with driver_wext), not reported by nl80211
> > > 
> > > 	--> dbm: used only if:
> > > 		* valid and zero max_qual->level (but now set to -110....) 
> > 
> > IIRC non-zero max_qual->level was the indication that the driver wanted
> > to use RSSI, not dBm.  Since the real "max" dBm is around 0 (ie, that's
> > the highest signal strength you'll ever really see), max_qual->level
> > meant the driver was reporting signal strength in dBm.  max_qual->level
> > == -110 is kinda wrong, because that's the _minimum_ level, not the max.
> This is very good point, a question for kernel developers, why it was
> set as such? How about setting it to ?
> 
> 
> > The noise floor is almost always around -100 dBm so setting
> > max_qual->level is pretty useless.
> > 
> > This is *exactly* why 'qual' is there: so that the driver itself can
> > figure out what the hell it's signal level is, and so that NM doesn't
> > have to go around assuming stuff.
> It appears as kernel developers want to drop quality calculations
> altogether, and report everything in dBms (right?) 
> This is also a consistent I think.
> 
> > 
> > For WEXT reporting, mac80211 should really be constructing a 'qual'
> > instead of leaving it 0.  Then we don't have ambiguities with dBm, RSSI,
> > unspec, etc.
> It does, but driver_nl80211 doesn't use wext that is.
> 
> 
> Also a recent conversation on linux-wireless indicated that noise level
> is a property of the wireless card, so I think we won't see them in scan
> results any time soon.
> 
> 
> Best regards,
> Maxim Levitsky
> 

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

On Mon, 2009-11-02 at 11:40 -0800, Dan Williams wrote:

> > 	--> dbm: used only if:
> > 		* valid and zero max_qual->level (but now set to -110....) 
> 
> IIRC non-zero max_qual->level was the indication that the driver wanted
> to use RSSI, not dBm.

Are you sure? Weird ... we've had it set at -110 practically forever in
mac80211-based drivers.

> Since the real "max" dBm is around 0 (ie, that's
> the highest signal strength you'll ever really see), max_qual->level
> meant the driver was reporting signal strength in dBm.  max_qual->level
> == -110 is kinda wrong, because that's the _minimum_ level, not the max.
> The noise floor is almost always around -100 dBm so setting
> max_qual->level is pretty useless.
> 
> This is *exactly* why 'qual' is there: so that the driver itself can
> figure out what the hell it's signal level is, and so that NM doesn't
> have to go around assuming stuff.
> 
> For WEXT reporting, mac80211 should really be constructing a 'qual'
> instead of leaving it 0.  Then we don't have ambiguities with dBm, RSSI,
> unspec, etc.

We do that -- I think the problem here is not the max_qual value but
that you're not getting a "qual" value since -Dnl80211 doesn't construct
that.

What effectively happens is that you're trying to discover device
capabilities based on wext, but then use the information provided by
nl80211, which while effectively the same information comes in a
different format. When using nl80211, you really should discover whether
the device uses dBm or RSSI values by the kind of attribute it gave you
in the scan result.

So IMHO the solution is to move all that "what kind of crap am I
getting" detection into driver_wext and only export the sanitised values
from wpa_supplicant.

johannes

PS: Please trim your quoting, it should be easy enough to kill
everything after your signature.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Alexander Sack]

On Mon, Nov 02, 2009 at 11:40:33AM -0800, Dan Williams wrote:
> On Sat, 2009-10-31 at 03:50 +0200, Maxim Levitsky wrote:
> > Sorry for cross-posting, but this issue really spans all three systems.
> > 
> > I anylized why I get 100% quality on all access points except currently
> > connected, when I used driver_nl80211 of wpa_supplcant.
> > 
> > First, when NetworkManager plans to switch to this driver?
> 
> Soon.  We've got some patches for this, but we'll also need tons of
> testing.  The WEXT stuff is pretty baked while nl80211 is still under
> some flux.  But of course the only way we bake nl80211 is by switching
> to it...

iirc, we currently we hardcode wext in NM code. How about adding a keyfile
config that users could use to switch to nl80211 until we feel confident
that it's good enough for everyone?

 - Alexander

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

On Mon, 2009-11-09 at 13:50 +0100, Alexander Sack wrote:

> > Soon.  We've got some patches for this, but we'll also need tons of
> > testing.  The WEXT stuff is pretty baked while nl80211 is still under
> > some flux.  But of course the only way we bake nl80211 is by switching
> > to it...
> 
> iirc, we currently we hardcode wext in NM code. How about adding a keyfile
> config that users could use to switch to nl80211 until we feel confident
> that it's good enough for everyone?

commit d27df100b587dd95f3256a8baf9db0c5d4380089 in wpa_supplicant allows
you to do that by editing the service file.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Marcel Holtmann]

Hi Johannes,

> > > Soon.  We've got some patches for this, but we'll also need tons of
> > > testing.  The WEXT stuff is pretty baked while nl80211 is still under
> > > some flux.  But of course the only way we bake nl80211 is by switching
> > > to it...
> > 
> > iirc, we currently we hardcode wext in NM code. How about adding a keyfile
> > config that users could use to switch to nl80211 until we feel confident
> > that it's good enough for everyone?
> 
> commit d27df100b587dd95f3256a8baf9db0c5d4380089 in wpa_supplicant allows
> you to do that by editing the service file.

that is funny, when I asked for a global command line switch for
choosing a different driver, the argument was that the application
adding the interface is suppose to do it by itself. Now we can do it in
the service file. Never the less ConnMan got its own switch to choose
which driver will be used. Does help a lot in testing and is way easier
since you don't have to restart wpa_supplicant all the time.

Regards

Marcel

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Dan Williams]

On Mon, 2009-11-09 at 14:09 +0100, Marcel Holtmann wrote:
> Hi Johannes,
> 
> > > > Soon.  We've got some patches for this, but we'll also need tons of
> > > > testing.  The WEXT stuff is pretty baked while nl80211 is still under
> > > > some flux.  But of course the only way we bake nl80211 is by switching
> > > > to it...
> > > 
> > > iirc, we currently we hardcode wext in NM code. How about adding a keyfile
> > > config that users could use to switch to nl80211 until we feel confident
> > > that it's good enough for everyone?
> > 
> > commit d27df100b587dd95f3256a8baf9db0c5d4380089 in wpa_supplicant allows
> > you to do that by editing the service file.
> 
> that is funny, when I asked for a global command line switch for
> choosing a different driver, the argument was that the application
> adding the interface is suppose to do it by itself. Now we can do it in
> the service file. Never the less ConnMan got its own switch to choose
> which driver will be used. Does help a lot in testing and is way easier
> since you don't have to restart wpa_supplicant all the time.

In reality, NM upstream will just switch over one day and distros that
use shitty and/or proprietary drivers will need to either (a) fix them,
or (b) patch NM to use wext locally.  That's how progress gets made.

Dan

Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211

[Marcel Holtmann]

Hi Dan,

> > > > > Soon.  We've got some patches for this, but we'll also need tons of
> > > > > testing.  The WEXT stuff is pretty baked while nl80211 is still under
> > > > > some flux.  But of course the only way we bake nl80211 is by switching
> > > > > to it...
> > > > 
> > > > iirc, we currently we hardcode wext in NM code. How about adding a keyfile
> > > > config that users could use to switch to nl80211 until we feel confident
> > > > that it's good enough for everyone?
> > > 
> > > commit d27df100b587dd95f3256a8baf9db0c5d4380089 in wpa_supplicant allows
> > > you to do that by editing the service file.
> > 
> > that is funny, when I asked for a global command line switch for
> > choosing a different driver, the argument was that the application
> > adding the interface is suppose to do it by itself. Now we can do it in
> > the service file. Never the less ConnMan got its own switch to choose
> > which driver will be used. Does help a lot in testing and is way easier
> > since you don't have to restart wpa_supplicant all the time.
> 
> In reality, NM upstream will just switch over one day and distros that
> use shitty and/or proprietary drivers will need to either (a) fix them,
> or (b) patch NM to use wext locally.  That's how progress gets made.

my goal is to run completely without wext driver in wpa_supplicant and
WEXT disabled in the kernel. However so far it caused some issues. I
think that most of them got fixed, but I never got around fully
verifying it. In the Moblin 2.0 timeframe we had for some time
nl80211,wext as driver selection, but unfortunately that never worked
out. I hope for Moblin 2.2 we are able to get this up and running.

One big missing piece is of course a new stable release of
wpa_supplicant that contains all the fixes.

Regards

Marcel