wpa_supllicant's nl80211 driver makes NetworkManager report 100 link quality for all access points

[Dan Williams]

On Wed, 2009-04-15 at 04:24 +0300, Maxim Levitsky wrote:
> On Tue, 2009-04-14 at 10:48 -0400, Dan Williams wrote:
> > On Sun, 2009-04-12 at 03:11 +0300, Maxim Levitsky wrote:
> > > Hi,
> > > 
> > > My goal is to cut down to minimum the time it takes to connect fully to
> > > an access point.
> > > 
> > > Due to that I want to use new and probably still unfinished nl80211
> > > wpa_supplicant driver.
> > > 
> > > It works with NetworkManager quite well (I patched wpa_supplicant to use
> > > nl80211 when NM asks for wext)
> > > 
> > > Except one thing: NM shows 100% quality on all access points.
> > 
> > What does the supplicant interface report for the BSSID's properties?
> > NM should prefer quality over level+noise, but NM may get the level
> > +noise calculation wrong, especially since the supplicant dbus interface
> > doesn't push the signal type (ie RSSI or dBm) through in the bssid
> > properties.
> > 
> > So there may need to be changes in both the supplicant's dbus interface
> > and NM.  But first, does the supplicant actually have 'quality' for the
> > scanned APs, or just level + noise?
> > 
> 
> Don't know what I was supposed to do exactly, but this is what wpa_cli
> shows, when I run it manually:

Ok, so there's a bug in the supplicant then (even in the normal control
interface) that it doesn't provide clients enough information to figure
out WTF 'signal level' actually means.  I assume you've hacked NM to use
the nl80211 driver or something (since NM hardcodes the WEXT driver).

I assert the supplicant should normalize signal level values in each
supplicant driver into either dBm or a "quality percent", and provide a
flag to indicate what the 'signal level' actually is.  Otherwise clients
have no hope of determining what the value coming out of the supplicant
is.

For nl80211, it's clearly dBm already.

For WEXT, it's *also* dBm, but it's in WEXT dbm, which is 8 bit with 0
being 256, so the real dBm for WEXT driver is (0 - (256 - level)), but
of course that depends on the kernel driver doing the right thing too,
since some kernel drivers report RSSI instead of dBm in WEXT.  So the
supplicant WEXT driver should probably do the dBm calculation internally
anyway.

In short, nl80211 itself provides enough information to figure this
stuff out, but the supplicant doesn't provide enough information to
clients so that *they* can figure out what the supplicant is proxying
from the kernel driver.

The supplicant should be fixed to either make drivers report level in
actual dBm, or add a new "signal-dbm" value in scan results that uses
dbm.

Dan


> 
> 
> driver_nl80211:
> 
> 
> > > scan_results
> > bssid / frequency / signal level / flags / ssid
> > 00:1b:9e:d8:77:02	2412	-48	[WPA2-PSK-CCMP] 
> > 02:22:15:02:16:cc	2462	-84	[WEP]	hisec
> > 00:21:63:ec:2e:e0	2437	-87	[WEP]	hisec2
> > 00:21:63:4c:41:34	2437	-78		RTA1025W-4C4134
> > 00:0e:2e:93:13:3f	2462	-84		default
> > 00:21:63:99:5b:a7	2437	-87		SIEMENS-995BA7
> > 00:11:6b:25:ac:6c	2462	-87		012Level1
> > > <2>CTRL-EVENT-TERMINATING - signal 2 received
> > 
> > 
> 
> 
> wext:
> 
> 
> bssid / frequency / signal level / flags / ssid
> 00:1b:9e:d8:77:02	2412	207	[WPA2-PSK-CCMP]	
> 02:22:15:02:16:cc	2462	170	[WEP]	hisec
> 00:21:63:4c:41:34	2437	178		RTA1025W-4C4134
> 00:21:63:76:b3:a4	2437	172		SIEMENS-76B3A4
> 00:21:63:73:3e:cb	2437	172		meravsh
> 00:0e:2e:93:13:3f	2462	172		default
> 00:1b:9e:89:a5:3f	2437	170		SIEMENS-89A53F
> 00:11:6b:29:b4:c0	2442	167		012-R
> 
> 
>