The checkbox to "Automatically start connecting next time" does not work for OpenConnect-based VPNs. Reproducible: Always Steps to Reproduce: 1. Select an OpenConnect-based VPN 2. In the connection dialogue, select "Automatically start connecting next time" 3. Click the button next to the server name to fetch connection information, enter your credentials, and hit Ok. 4. Disconnect again. 5. Connect again. Actual Results: The connection information is not fetched automatically. I have to press that button next to the server name. Expected Results: The connection information should be fetched automatically, without pressing any additional buttons. This used to work fine. I don't know what broke it though, downgrading plasma-nm does not seem to fix the issue. Btw, that button which starts the connection process is very unintuitive - it took me some minutes to figure out I need to click it in order to establish a connection.
I thought I fixed this in commit cd9b70f1422. However, ISTR there was some weirdness with the way the plugin was remembering secrets. A checkbox for whether secrets were kept system-wide or per-user, and if you checked the wrong one then it just failed to remember the secrets at all. I only vaguely remember this, and only looking at it hard enough to establish that it was probably Not My Fault™. Since the 'autoconnect' option is stored as a "secret" as far as NM is concerned, that might be the cause of this issue.
Git commit 4bb0e742dd9f8cede51af590c4a228656e8a73d9 by Jan Grulich. Committed on 08/01/2015 at 12:44. Pushed by grulich into branch 'master'. Do not return an empty map with secrets This is causing some issues in secret agent from plasma-nm, because it always tries to store VPN secrets to KWallet even when the map is empty and when it loads this empty map later it overwrites the secrets we get from NetworkManager in GetSecrets method and thus when plasma-nm displays the auth dialog it doesn't have necessary secrets available. Related: bug 309931, bug 334474 M +3 -1 src/settings/vpnsetting.cpp http://commits.kde.org/networkmanager-qt/4bb0e742dd9f8cede51af590c4a228656e8a73d9
Git commit 1da5311c003b598ca5d371a1e814847ffcf8d608 by Jan Grulich. Committed on 08/01/2015 at 12:41. Pushed by grulich into branch 'master'. Workaround: make sure we don't send completely empty map to NM back when asking for VPN secrets When NM asks for secrets, which should be system-owned (stored in NM), it also asks our secret agent from some reason if we have them, but if we send back an empty map, it won't ask again with required flag which would invoke displaying an auth dialog. We have to send back a map containing "secrets" key which should be without any value. It worked before that way because in NetworkManagerQt we always returned this map with secrets even when it was empty. Related: bug 309931, bug 334474 M +11 -1 kded/secretagent.cpp http://commits.kde.org/plasma-nm/1da5311c003b598ca5d371a1e814847ffcf8d608
Git commit 5c908dfb4b075d001cd1f2b43494e19ed18f1ba1 by Jan Grulich. Committed on 08/01/2015 at 12:44. Pushed by grulich into branch 'NM/0.9.8'. Do not return an empty map with secrets This is causing some issues in secret agent from plasma-nm, because it always tries to store VPN secrets to KWallet even when the map is empty and when it loads this empty map later it overwrites the secrets we get from NetworkManager in GetSecrets method and thus when plasma-nm displays the auth dialog it doesn't have necessary secrets available. Related: bug 309931, bug 334474 M +3 -1 settings/vpnsetting.cpp http://commits.kde.org/networkmanager-qt/5c908dfb4b075d001cd1f2b43494e19ed18f1ba1
Git commit 20e8f2d6924b90492074221a2c3d971eb9c52112 by Jan Grulich. Committed on 08/01/2015 at 12:41. Pushed by grulich into branch '0.9.3'. Workaround: make sure we don't send completely empty map to NM back when asking for VPN secrets When NM asks for secrets, which should be system-owned (stored in NM), it also asks our secret agent from some reason if we have them, but if we send back an empty map, it won't ask again with required flag which would invoke displaying an auth dialog. We have to send back a map containing "secrets" key which should be without any value. It worked before that way because in NetworkManagerQt we always returned this map with secrets even when it was empty. Related: bug 309931, bug 334474 M +11 -1 kded/secretagent.cpp http://commits.kde.org/plasma-nm/20e8f2d6924b90492074221a2c3d971eb9c52112