wpa_supplicant roaming question

[Matt Causey]

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?

Cheers,

--
Matt


>
> BR
> Janusz
>