Why does iwlist scan return cached results almost every time?

4
votes

I've got a set top box running linux kernel 2.6.32 (cannot upgrade, please don't suggest that). I'm using the Realtek 8192CU driver configured to use the WEXT driver. What would cause iwlist scan to constantly return cached results? It seems when the STB boots and does its first scan, it gets an accurate list and connects to an access point just fine. However, subsequent scans return the exact same info (even signal strengths and qualities are identical).

Rarely, a scan will return new results, but I can't find any pattern to the period of time between successful scans (sometimes hours).

When a new result set is available there is a 'survey done event(xx)' message in dmesg.

Using wpa_cli, I run the following command and get a response.

>scan ra0
OK
<3>CTRL-EVENT-SCAN-RESULTS

However, 'wpa_cli scan_results' returns the exact same cached information as iwlist and there is NO 'survey done event(xx)' message in dmesg.

Can anyone shed any light on what might be going on here? I would like to figure out how to reliably trigger a scan for new APs.

Thanks for any help in advance!

2
linux-kerneldriverwireless
It has been a while, but I think wpa_supplicant has configuration settings available to make it more proactive in discovering new access points. Of course, most of that behavior results in how it calls into the WEXT extentions of the driver. - Peter L.
It's not just not discovering new APs, though. Event the strengths of the current APs are not being updated. It looks as though the scan is never being done. - skissors

2 Answers

5
votes

Ran into the same problem. Discovered that if you run the command as root, it appears to reset the cache every time.

3
votes

Hopefully someone finds this useful.

After tons of digging through the 8192cu driver, it seems that it will not initiate a scan if it deems itself to be "busy" with traffic. It will just return cached scan results. In the environment I had the hardware installed, there was a lot of multicast traffic causing it to be "busy" almost all the time.

To fix this, I had to edit one line in core/rtw_cmd.c. Here's the diff.

1826c1826,1829
<       if( pmlmepriv->LinkDetectInfo.NumRxOkInPeriod > 100 ||
---
>       //  in large networks with lots of multicast traffic,
>       //  I needed to increase the Rx threshold for bBusyTraffic
>       //  so that AP scanning would work
>       if( pmlmepriv->LinkDetectInfo.NumRxOkInPeriod > 500 || // 100 ||
1831c1834
<           if(pmlmepriv->LinkDetectInfo.NumRxOkInPeriod > 100)
---
>           if(pmlmepriv->LinkDetectInfo.NumRxOkInPeriod > 500) // 100)