wpa_supplicant roaming question

[Matt Causey]

Ha!  Yeah that's pretty lame on my part.  I was convinced that I'd
configured the supplicant properly at compile time, but alas I was
wrong.  I went back and re-compiled and now it works as expected.  :-)

I have another question now...I notice that if the supplicant
processes a disassociation or deauth, we call
wpa_supplicant_event_disassoc() (in blacklist.c), which then adds that
BSSID to a blacklist.  Then, the supplicant can no longer roam to that
BSSID, even if it is a better choice.

In our use case, we have a large number of access points and they can
drop offline for maintenance periodically.  What would folks recommend
we do to keep these BSSID's from becoming permanently blacklisted just
because they needed to reboot?

--
Matt


On Wed, Aug 31, 2011 at 4:21 AM, Janusz Dziedzic
<janusz.dziedzic at gmail.com> wrote:
> 2011/8/30 Matt Causey <matt.causey at gmail.com>:
>> Hello,
>>
>> I have a question about how scans are meant to be triggered with
>> wpa_supplicant, mac80211, and family. ?At my site, we have a fleet of
>> small devices that run the Atheros ar928x wireless cards. ?We use
>> EAP-TLS on Motorolla WLAN infrastructure. ?We're running linux
>> 2.6.38-2 with no vendor patches. ?Our wpa_supplicant version is 0.7.3.
>>
>> In our situation, we'll have a client adjacent to 2 or 3 BSSIDs
>> broadcasting the same ESSID, and the client moves about from time to
>> time. ?What I am seeing is that the client will sit on a -70 access
>> point, without roaming, for hours even in the presence of another
>> access point that registers as -50. ?However, if I do something to
>> manually trigger a scan, the device will suddenly roam to the more
>> favorable access point.
>>
>> For example, I can do 'iwlist scan', or HUP the supplicant. ?iwlist I
>> am sure causes the driver to generate a new set of scan results -
>> which the supplicant picks up and uses. ?HUP of the supplicant causes
>> the supplicant to call wpa_supplicant_req_scan(), and then roam as a
>> result of the new scan data. ?This leaves me thinking that the roaming
>> algorithm is working great, it's just that the background scanning is
>> not working as I would expect...
>>
>> So I read about bgscan here:
>> http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap-07.git;a=commit;h=e2f74005f548d90014cdf080802d455382e37cb9
>>
>> It looks like what I want - to configure the supplicant to scan
>> periodically. ?However I have it enabled and I don't ever see it kick
>> in. ?Any ideas why?
>>
>> Here is our supplicant config:
>>
>> network={
>> ? ? ? ?ssid="wpa2"
>> ? ? ? ?bgscan="simple:30:-45:300"
>> ? ? ? ?freq_list=<a list of the frequencies that we use>
>> ? ? ? ?identity="<client-id>"
>> ? ? ? ?key_mgmt=WPA-EAP
>> ? ? ? ?proto=WPA2
>> ? ? ? ?pairwise=CCMP
>> ? ? ? ?group=CCMP
>> ? ? ? ?eap=TLS
>> ? ? ? ?ca_cert="/etc/cert/root.pem"
>> ? ? ? ?client_cert="/etc/cert/user_cert.pem"
>> ? ? ? ?private_key="/etc/cert/user_key.pem"
>> ? ? ? ?private_key_passwd="<noober mic nooberson>"
>> }
>>
>> If there is other info I can provide please let me know!
>>
>
> Did you enable this CONFIG_BGSCAN_SIMPLE=y in wpa_supplicant/.config
> file before compilation?
>
> We are using bgscan simple and learn and don't have such problems.
> If still an issue:
> Run wpa_supplicant with -ddd option. After that you should get debug
> messages connected with bgscan_simple.
>
> BR
> Janusz
>