Version: 0.9 (using KDE 4.6.3) OS: Linux I am using: NetworkManager-0.8.9997-4.git20110620.fc15.x86_64 kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15.x86_64 I have a WPA-PSK connection in range and set to connect automatically. But kde-plasma-networkmanagement won't actually connect automatically to it, I have to connect by hand. (In case it matters, the PSK is stored in KWallet.) Reproducible: Always Steps to Reproduce: 1. Set a WPA-PSK connection to connect automatically. 2. Boot. 3. Log in. Actual Results: Nothing happens. If I connect manually, it connects. Expected Results: It connects automatically. I'm not 100% sure that this is really ALWAYS reproducible, but it looks close enough at least. Other Fedora 15 users with the same versions of the packages are also seeing this.
NM's clients just add the auto-connect setting, it is NM daemon that triggers the connection process. Can you check if the connection really has the auto-connection setting by asking NM directly (throught DBus)? If so then there is nothing we can do from here.
Actually, these are my logs (relevant excerpt): Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Auto-activating connection 'kk'. Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Activation (wlan0) starting connection 'kk' Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled... Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started... Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled... Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete. Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting... Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0] Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Activation (wlan0/wireless): access point 'kk' has security, but secrets are required. Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0] Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Jun 27 00:01:33 laptop64 NetworkManager[722]: <warn> No agents were available for this request. Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> (wlan0): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7] Jun 27 00:01:33 laptop64 NetworkManager[722]: <warn> Activation (wlan0) failed for access point (kk) Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> Marking connection 'kk' invalid. Jun 27 00:01:33 laptop64 NetworkManager[722]: <warn> Activation (wlan0) failed. Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> (wlan0): device state change: failed -> disconnected (reason 'none') [120 30 0] Jun 27 00:01:33 laptop64 NetworkManager[722]: <info> (wlan0): deactivating device (reason: 0). So what happens is that NM tries to autoconnect, but doesn't get the secrets (the PSK) and so fails. (Race condition?)
(When I connect manually later on, the secret is provided and so the connection succeeds at that point.)
I do not think so. Maybe it is a problem with the kded module, where our secret agent is implemented. Can you logout / login and test again? This can also be caused by the fact that NM is saving incorrect secrets with our secret agent. Until we fix that problem several other problems can be just a duplicate of that bug. There is also the fact that NM temporaly disables auto-connect if you click on the disconnect button. It will be re-anable when the user clicks on the connect button.
Looks like this is this NetworkManager bug: https://bugzilla.redhat.com/show_bug.cgi?id=706204 which is fixed in upstream NetworkManager commit 69b767bbf0ef8e038dd8bd0bcb35586c0f91ade7 and NetworkManager-0.8.9997-5.git20110702.fc15. It is indeed a race condition as I suspected (NM tries to connect before the secret agent is registered), but there's a fix in NM now (it automatically retries when the secret agent is ready). Let's hope it works.
Confirmed fixed in NetworkManager-0.8.9997-5.git20110702.fc15 (i.e. this was really an upstream NetworkManager issue, which is now fixed).