On 06/08/2020 04:41 PM, Kevin Lund wrote:
If you reload the station configuration in the supplicant (but not restart
the supplicant process), will the blacklisting be cleared as part of this
reload?
Hello,
The only ways the blacklist should be cleared after this change should be 1. the supplicant is shut down/restarted, 2. we run a scan and don't > find any APs, 3. a clear is requested directly through the ctrl interface, or 4. a long time (>1hr) passes (this is implemented in patch 3/4 in this > series). When reloading configuration parameters I don't think anything meets that criteria.
If you have a bad password configured, then AP will get in the blacklist (I think?), and so then if user
reconfigures to fix the password, we should clear the blacklist so that the AP can be used?
You can reload station config without restarting supplicant.
So, I think that reloading the supplicant config should clear blacklist at least for that
station.
Good point. That use case seems legitimate, but I'm not familiar with
all the triggers that cause the supplicant to reload configs. My
concern is that there may be other triggers to reload the configs
which could potentially interfere with the intended blacklist behavior
in some circumstances. After all, being too lenient with clearing the
blacklist is what caused this issue in the first place.
Just hook into the method that handles the reload, then no matter what triggers it,
it will work.
Reloading is functionally similar to restarting the supplicant, so I think it will
be fine to clear it there.
Having a legit AP blacklisted for a long time due to local mis-config is a serious problem.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
