wext: Fix scan result signal levels when driver reports in dBm
authorDavid A Benjamin <davidben@MIT.EDU>
Sun, 5 Sep 2010 16:04:10 +0000 (19:04 +0300)
committerJouni Malinen <j@w1.fi>
Mon, 4 Oct 2010 05:25:00 +0000 (08:25 +0300)
commit32f4e7b124f918a49de493b6adb068d7054dae5a
tree16d65c3e7061f4f1777584d80ffef0c125b48f22
parent8602b0f21325ed32642c90b6ecbef0721e34083c
wext: Fix scan result signal levels when driver reports in dBm

wpa_supplicant showed signal levels incorrectly with some drivers:
Jun  6 16:29:36 rupert wpa_supplicant[18945]: Current BSS: 00:0d:97:11:40:d6
level=190
Jun  6 16:29:36 rupert wpa_supplicant[18945]: Selected BSS: 00:0d:97:11:50:09
level=192

Judging from output from other tools (iwlist) and the min_diff block
at the end of wpa_supplicant_need_to_roam, it seems these values
should actually be negative. Specifically, if one treats that number
as a signed char instead of unsigned, everything matches up.

To be honest, I've little to no understanding of wireless, but looking
at the source code for wireless-tools (iw_print_stats in iwlib.c), it
seems that the fields of the iw_quality struct need to be decoded
differently depending on various flags. I guess
src/drivers/driver_wext.c should have similar logic in
wext_get_scan_qual.

I wrote a patch that attempts to replicate some of that logic,
although it may be more complicated than is necessary; I think some of
the complexity is for backwards-compatibility, which might not be
necessary depending on wpa_supplicant's dependencies? In any case, it
is attached. Again, I don't know how any of this works, so it's likely
the patch is a bit off. But I think at least the logic to determine
min_diff in wpa_supplicant_need_to_roam would be more accurate if
level were determined correctly.
src/drivers/driver_wext.c
src/drivers/driver_wext.h