wpa_supplicant roaming question

[Janusz Dziedzic]

2011/9/1 Matt Causey <matt.causey at gmail.com>:
> On Thu, Sep 1, 2011 at 1:17 AM, Janusz Dziedzic
> <janusz.dziedzic at gmail.com> wrote:
>> 2011/8/31 Matt Causey <matt.causey at gmail.com>:
>>> 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?
>>>
>>
>> Seems this is true. Blacklist will be cleared if "No APs found".
>>
>> In case of our implementation we don't hit this problem. We have
>> additional CQM signal - beacon_miss - from our driver (nl80211). Count
>> of beacon_miss is configurable from supplicant when bgscan starts. Our
>> firmware support this beacon_miss detection - so, it is usefull - we
>> can roam before deauthenitcation in case someone will switch off AP or
>> we loose connection.
>> I think we will push this CQM cfg80211/nl80211 compat-wireless +
>> hostap implementation soon.
>>
>> So, in case someone will switch off AP, before we will get
>> deauthentication we get this beacon_miss event and we have chance to
>> roam to another APs. If there isn't another APs blacklist will be
>> cleared because of "No APs found".
>>
>
> Interesting. ?So you have events that get processed before a deauth
> happens. ?Even with that, it is only a matter of time before your
> client receives a deauth for some other reason that does not correlate
> with a missed beacon, and then you will be vulnerable to the same
> issue.
>
> This functionality as it stands is a show-stopper for us so I've
> commented out the call to wpa_blacklist_add()
> (http://hostap.epitest.fi/wpa_supplicant/devel/blacklist_8c.html#af59c8fe6b0bef5b49f433bd06b29e9ab).
> ?I kind of wish that we could at least configure this behavior because
> it's pretty broken currently. ?I can see the rationale...the idea is
> that if a BSSID is impaired in some way, but is the strongest BSSID
> for a network, then clients will go there and have a bad experience.
> Unfortunately I think that the heuristic needs more work.
>
> Now, it may be that I can get ath9k to produce similar events that
> prevent the supplicant from processing the deauth, thus preventing the
> bug in the same way you are. ?Where in the driver would one typically
> look to see what, if any, 80211 events are supported?
>

In case of black_list  - maybe good idea is to add time parameter for
each blacklisted AP.
In such case we could add APs to blacklist for specyfic amount of time
period. After this time APs will be removed from blacklist.

BR
Janusz