wpa_supplicant: Problem with freq_list scan filter

Janusz Dziedzic janusz.dziedzic
Fri Aug 8 03:05:18 PDT 2014

On 8 August 2014 11:36, Bojan Prtvar <bojan.prtvar at rt-rk.com> wrote:
> Hi Janusz,
> On 08/08/2014 09:23, Janusz Dziedzic wrote:
>> On 7 August 2014 16:05, Bojan Prtvar <bojan.prtvar at rt-rk.com> wrote:
>>> Hello,
>>> Background:
>>> We are using wpa_supplicant (v2.0-devel-4.2.2)on Android embedded device.
>>> We had a requirement to support only networks in 5GHz range. In order to
>>> support it, we back-ported [1] patch and added config option
>>> freq_list=5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560
>>> 5580 5600 5620 5640 5660 5680 5700
>>> After this, Android only reports networks from 5GHz range and everything
>>> seemed OK.
>> So, small change to android framework and adding
>> bssid=f8:d1:11:a6:1b:b0 to network block.
>> Should fix the issue.
> No. Devices are planned for mass production. MAC addresses I provided in
> the log, are just examples from the test lab.
> Requirement is to support only networks from 5GHz range, not an AP with
> a specific MAC.
You should have bssid in scan results (same like ssid, encryption ...)
list in android. So, you can set this when user will choose network.
But still other problem is if roaming required for 5GHz :)

>>> Problem statement:
>>> There is a problem in following scenario.
>>> We have two networks(same ssid,same password) one in 5GHz other in 2GHz
>>> range. We connect  device to supported 5GHz network, and then turn off
>>> that AP. After a while, device automatically connects to unwanted 2GHz
>>> network. Please find wpa_supplicant logs in [2].
>>> 5GHz AP is f8:d1:11:a6:1b:b0
>>> 2GHz AP is f8:d1:11:c4:4b:dc
>>> Could this be a wpa_supplicant issue or Android WiFi framework is to blame?
>>> Any help would be highly appreciated.
>> Seems like supplicant bug? Back to scan all freq?
> I think it is a supplicant bug, If my understanding of freq_list is correct:
> "Scan _only_ frequencies which are provided, scan all frequencies if the
> freq_list is not set."
> So if the freq_list option is set, upper layers should never be aware of
> any network from the range which is not set.
You have to check the code, fix if needed.
Could be also driver don't care about scan_list and scan all freq in
some cases (in such case you can workaround this and remove scan
results in supplicant base on freq_list?).


More information about the Hostap mailing list