kern/48390: wifi signal strength always reported as zero

[apb%cequrux.com@localhost]

>Number:         48390
>Category:       kern
>Synopsis:       wifi signal strength always reported as zero
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 20 20:20:01 +0000 2013
>Originator:     Alan Barrett
>Release:        NetBSD 6.99.25
>Organization:
Not much
>Environment:
System: NetBSD 6.99.25
Architecture: i386
Machine: i386
>Description:
        When there are multiple wifi access points with the same
        SSID, wpa_supplicant makes no attempt to use the one with the
        best signal/noise ratio.  Instead, it seems to use any access
        point, in some arbitrary order of preference.  Sending the
        "reassociate" command via wpa_cli makes it try another access
        point, and if this is repeated often enough then wpa_supplicant
        may eventually choose the desired access point.

        I am classifying this as a kernel bug, because the underlying
        problem seems to be that the signal strength is always reported as
        zero, so it's unreasonable to expect wpa_supplicant to make a
        good choice.

        In case it matters, the hardware is probed as follows:

        athn0 at pci2 dev 0 function 0: Atheros AR9285
        athn0: rev 2 (1T1R), ROM rev 14, address b4:xx:xx:xx:xx:xx
        athn0: interrupting at ioapic0 pin 16
        athn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
        athn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 
24Mbps 36Mbps 48Mbps 54Mbps

>How-To-Repeat:
        Go to a place that has many access points on the same SSID.

        Run wpa_supplicant:

        $ /usr/sbin/wpa_supplicant -B -i athn0 -c /etc/wpa_supplicant.conf \
                -ddtf/var/log/wpa_supplicant.debug

        A wifi monitor running on an Android phone reports that one of
        the access points has a much higher signal strength than all the
        others, but wpa_supplicant doesn't know this, as can be seen
        through wpa_cli.

        Run wpa_cli, and observe that all access points have signal
        strength 0:

        $ wpa_cli
        Selected interface 'athn0'
        Interactive mode
        > scan_results
        21:24:21.057: bssid / frequency / signal level / flags / ssid
        f8:xx:xx:xx:xx:f6       2432    0       [ESS]   XXXX
        f8:xx:xx:xx:xx:a7       2417    0       [ESS]   XXXX
        f8:xx:xx:xx:xx:d3       2437    0       [ESS]   XXXX
        f8:xx:xx:xx:xx:86       2417    0       [ESS]   XXXX
        f8:xx:xx:xx:xx:23       2447    0       [ESS]   XXXX
        f8:xx:xx:xx:xx:83       2432    0       [ESS]   XXXX
        f8:xx:xx:xx:xx:64       2412    0       [ESS]   XXXX
        > status
        [...] bssid=f8:xx:xx:xx:xx:f6
        [...]
        > reassociate
        [...] OK
        [...] CTRL-EVENT-DISCONNECTED bssid=f8:xx:xx:xx:xx:f6 reason=0
        [...] CTRL-EVENT-SCAN-RESULTS
        [...] Trying to associate with f8:xx:xx:xx:xx:f6 [...]
        [...] Associated with f8:1a:67:ec:cf:f6
        [...] CTRL-EVENT-CONNECTED - Connection to f8:xx:xx:xx:xx:f6 [...]

        (Notice that it disconnected and re-associated with the same
        access point.)

        > reassociate
        [...] OK
        [...] CTRL-EVENT-DISCONNECTED bssid=f8:xx:xx:xx:xx:f6 reason=0
        [...] CTRL-EVENT-SCAN-RESULTS
        [...] Trying to associate with f8:xx:xx:xx:xx:83 [...]
        [...] Associated with f8:1a:67:ec:cf:83
        [...] CTRL-EVENT-CONNECTED - Connection to f8:xx:xx:xx:xx:83 [...]

        (This time, it re-associated with a different acecss point.
        Repeat until it eventually chooses an access point with a usable
        signal strength.)

>Fix:
        Make the device driver report the signal strength to
        wpa_supplicant.  (I assume, but have not checked, that
        wpa_supplicant will then sue that information to choose the
        access point with the best signal.)

        Workaround: manually issue "reassociate" commands to wpa_cli
        as many times as necessary to make wpa_supplicant choose the
        "right" acecss point.