Windows netsh caches BSSID signal strength for a long time

[KrisKusano]

Issue

The command used for WindowsWifiScanner.get_cmd is:

netsh wlan show networks mode=bssid

It appears Windows uses caching for this command. The result is that the same SSID/BSSID list is printed for a long time (including signal strength). On my machine, the signal strength does not change for more than 1 minute after I physically move around my house. This is not good behavior for scanning applications, e.g. whereami

Possible Solutions

Disable/Enable Interface

Per this solution, disable/enable the wireless interface. Change WindowsWifiScanner.get_cmd to

class WindowsWifiScanner(WifiScanner):

    def get_cmd(self):
        return 'netsh interface set interface name="Wireless Network Connection" admin=disabled && ' + \
            'netsh interface set interface name="Wireless Network Connection" admin=enabled && ' + \
            "sleep 4 && " + \
            "netsh wlan show networks mode=bssid"

Explanation:

• line 1 and 2: enable and disable interface
• line 3: wait for interface to come back up (netsh is unavailable until the interface is up)
• line 4: original

This is not ideal because:

• Has to execute on administrator command prompt
• Interface name is different per machine (name="Wireless Network Connection")
• This is really slow because of the need to sleep

Pure Windows API

Use .NET API to access this information. Looks not fun, I have not investigated (see here and here)

Next steps

I do not think either is an acceptable solution.

Other items to check:

• Is if there is some hardware settings in Windows to prevent caching?
• Is there some python interface to the WinAPI that can access the native Wifi info?

[ScottSWu]

I ran into this same problem with schollz/find, ended up solving it by creating an alternative to netsh https://github.com/ScottSWu/windows-wlan-util/blob/master/windows-wlan-util/windows-wlan-util.cpp. Unfortunately, the sleep was still necessary since initiating the scan was asynchronous, and it took up to 10 seconds to fully populate the list.

My use case is localization in a known space, so the delay was OK since we had lots of time and devices to train with. Otherwise, it looks like digging deeper into hardware / drivers will be the best bet.