Bug 98218 - wpa_supplicant(8) blacklist not working
Summary: wpa_supplicant(8) blacklist not working
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: 7.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
Depends on:
Reported: 2006-05-31 15:50 UTC by Kevin Oberman
Modified: 2018-05-28 19:43 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Oberman 2006-05-31 15:50:15 UTC
	If multiple BSSes match an entry in the wpa_supplicant.conf
file, it is possible that the BSS chosen will not associate, but
instead of blacklisting the BSS and trying another, the wpa_supplicant
continues to try to attach to the unusable BSS with a new attempt every
10 seconds.

This was observed in a non-secured situation. That is there were
multiple BSSes showing in the scan and the first had a very low signal
strength. The supplicant would try to associate with that BSS, but
could not. ifconfig always showed the interface with no carrier.

I believe that the supplicant should have blacklisted that BSS and
tried another on the list, but would keep trying the same one over and
over. Restarting the supplicant would cause a new list of BSSes to be
generated which was identical to the first except for order. If the
first BSS on the list proved functional, association would take place
and things progressed normally. If the first entry would not
associate, the same thing, re-attempts to associate with the same BSS
every 10 seconds would repeat.

For the record, the configuration file in question was my generic
wireless of:

My wireless card is an Atheros 5212, although inspection of the code
leads me to believe that this is not related to the card chosen.


Modify the supplicant to blacklist a BSS that fails to associate so
that other available APs will be tried.
How-To-Repeat: 	Attempt to use the wpa_supplicant in an environment where
several APs are available, some of which have poor signals and will
not associate.
Comment 1 Volker Werth freebsd_committer 2009-01-14 23:27:31 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 Christian Brueffer freebsd_committer 2014-02-19 15:52:12 UTC
State Changed
From-To: open->feedback

Hi Kevin, wpa_supplicant has been updated since this PR was filed.  Do you 
still see this behaviour in newer FreeBSD releases?
Comment 3 Christian Brueffer freebsd_committer 2014-02-19 16:57:32 UTC
State Changed
From-To: feedback->closed

Hi Kevin, thanks for the quick answer and sorry this PR sat around for so 
long.  I close the PR with this, but in case you come into the situation where 
you can test this again, we'd be happy to hear your report. 

Happy retirement!
Comment 4 Christian Brueffer freebsd_committer 2014-02-19 19:27:18 UTC
State Changed
From-To: closed->open

Adrian says this is likely still an issue, open and assign to freebsd-wireless at his request. 

Comment 5 Christian Brueffer freebsd_committer 2014-02-19 19:27:18 UTC
Responsible Changed
From-To: freebsd-net->freebsd-wireless

Adrian says this is likely still an issue, open and assign to freebsd-wireless at his request.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:43:18 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.