On Fri, 2020-10-23 at 10:28 +0200, Guillaume Betous wrote:
Thanks, I'll try to take more longs next time we reproduce it.If the password is wrong, then autoactivation gets blocked indefinitely (or until a new secret agent connects who could provide the password).In my case, password is OK for sure (because I don't modify the config file, and I can manually connect). It seems to be some timeout issue. Do you think it can be the same kind of blacklist behavior ?
Hi, hard to say. NM does not do such blacklisting. NM will try to autoactivate a profile repeatedly (and ratelimit autoconnect for a few minutes after "connection.autoconnect-retries" failures). autoconnect can be blocked also by: - with `nmcli device disconnect` the device gets blocked from autoconnect (until the user(*) manually activates it again). - with `nmcli connection down` blocks autoconnect of the profile indefinitely, until the user(*) unblocks it. - having wrong secrets, what I talked about before. Saying "password is OK for sure" doesn't matter. I said, NetworkManager and/or wpa_supplicant might wrongly think the psk is wrong. - before [1], a profile that never successfully autoconnected, might also not be able to autoconnect. See commit message of [1]. But without useful logs that is rather hard to say. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commits/835175e4fb49904e536a3ed23205ca668a14cc1d (*) the "user" is of course merely a program that uses NetworkManager's D-Bus API. It does not necessarily mean a human. best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part