Re: [PATCH v2 2/4] wpa_supplicant: Implement time-based blacklisting
Ben Greear <[email protected]> Mon, 8 Jun 2020 16:45:32 -0700
| Newsgroups | gmane.linux.drivers.hostap |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> Candela Technologies Inc http://www.candelatech.com