Summary: | Does not connect automatically (20110616 nm09 snapshot) | ||
---|---|---|---|
Product: | Network Management | Reporter: | Kevin Kofler <kevin.kofler> |
Component: | KDED Module | Assignee: | Will Stephenson <wstephenson> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | collura, lamarque, rdieter |
Priority: | NOR | ||
Version: | 0.9 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Kevin Kofler
2011-06-26 22:19:30 UTC
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). |