wpa_supplicant roaming question

[Matt Causey]

On Thu, Sep 1, 2011 at 3:53 PM, Janusz Dziedzic
<janusz.dziedzic at gmail.com> wrote:
> 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.
>

I would agree with that.  It might also be useful to make that
configurable rather than a compile-time option.

Even with a time value, though, I'm thinking that there will be some
edge cases that we'll discover.  I am not sure that it's the
supplicant's job, actually, to blacklist BSSIDs at all.  I would
submit that if we have an ESSID with multiple BSSIDs in the first
place, we're talking about an enterprise network or at the very least
a network that should have some robust management in place.  And if a
network like that has BSSID's out there that are broken, it isn't the
client's job to work around that.  Roaming to another (uh, weaker)
access point isn't really a solution.

I'm just curious...what was the failure mode that precipitated the
blacklist feature enhancement to wpa_supplicant?

Thanks!

--
Matt