I've set up an openconnect VPN connection through plasma-widget-networkmanagement, but it doesn't remember important settings. (See the attached image). 1) It doesn't remember the "VPN host" (that drop down menu has four options). 2) Checking "Automatically start connection next time" does absolutely nothing. It doesn't cause the VPN to connect at startup; it doesn't reconnect if the connection temporarily goes down; and it doesn't even stay checked when I next open that window. 3) It doesn't remember the "Group" (that drop down menu has five options). 4) it doesn't remember the "PASSCODE". The only thing on that window it remembers is my Username. I can use a cisco client that stores everything but the password, but I'd much prefer to use the KDE client since it's much more nicely integrated with the desktop and I use it for other VPN connections. (plasma-widget-networkmanagement does a much better job with other types of VPN connections I use.) Reproducible: Always
Created attachment 75184 [details] The dialog that shows up every time I try to connect.
(In reply to comment #0) > I've set up an openconnect VPN connection through > plasma-widget-networkmanagement, but it doesn't remember important settings. > (See the attached image). > 1) It doesn't remember the "VPN host" (that drop down menu has four options). > 2) Checking "Automatically start connection next time" does absolutely > nothing. It doesn't cause the VPN to connect at startup; it doesn't > reconnect if the connection temporarily goes down; and it doesn't even stay > checked when I next open that window. > 3) It doesn't remember the "Group" (that drop down menu has five options). > 4) it doesn't remember the "PASSCODE". > > The only thing on that window it remembers is my Username. I can use a cisco > client that stores everything but the password, but I'd much prefer to use > the KDE client since it's much more nicely integrated with the desktop and I > use it for other VPN connections. (plasma-widget-networkmanagement does a > much better job with other types of VPN connections I use.) > > Reproducible: Always
Sorry, pressed ENTER too soon. (In reply to comment #0) > I've set up an openconnect VPN connection through > plasma-widget-networkmanagement, but it doesn't remember important settings. > (See the attached image). Which Plasma NM version do you use? You can see the version string in "Manage Connections" -> "Other". > 1) It doesn't remember the "VPN host" (that drop down menu has four options). > 2) Checking "Automatically start connection next time" does absolutely > nothing. It doesn't cause the VPN to connect at startup; it doesn't > reconnect if the connection temporarily goes down; and it doesn't even stay > checked when I next open that window. This is an upstream issue, there is nothing we can do about that. > 3) It doesn't remember the "Group" (that drop down menu has five options). > 4) it doesn't remember the "PASSCODE". Do you have problem saving settings of other connection types (wifi for instance)? > The only thing on that window it remembers is my Username. I can use a cisco > client that stores everything but the password, but I'd much prefer to use > the KDE client since it's much more nicely integrated with the desktop and I > use it for other VPN connections. (plasma-widget-networkmanagement does a > much better job with other types of VPN connections I use.)
(In reply to comment #3) > Which Plasma NM version do you use? You can see the version string in > "Manage Connections" -> "Other". The version string reads, "Version 0.9.0.5 (nm09 20120930)". > This is an upstream issue, there is nothing we can do about that. If the check box doesn't work, can you get rid of it? Regardless of the upstream issue, having a check box that doesn't do what it claims to do is a bug with the interface -- which I'm assuming is part of the widget. > Do you have problem saving settings of other connection types (wifi for > instance)? No. It has no problems remembering wifi networks or passwords and connecting to them automatically. Like I said, it also has no problem with the other VPN I use (using VPNC, I think). With that, I can just click on the VPN icon and I'm automatically connected; I don't need to re-enter three things every time.
A correction: Once I select the right "VPN Host", it selects the "Group" I chose previously (the last time I used the interface). However, that "Group" option isn't available for the "VPN Host" it selects initially, and it doesn't start with the "VPN Host" that I chose previously. So, the interface does seem to remember the "Group" option.
Created attachment 75429 [details] bugfix Can you try the attached patch?
Is that directed at me? If so, I'm not sure how to do that, so please advise.
I see you're running Ubuntu, so I guess the easiest way would be to build a custom package. Open a terminal, then run apt-get build-dep plasma-widget-networkmanagement apt-get source plasma-widget-networkmanagement This will download and install all the required dependencies, then it will download and extract the source. You sould have a directory networkmanagement now. Copy the patch to networkmanagement/debian/patches/openconnect.patch, then open networkmanagement/debian/patches/series with your favorite editor and add a line with openconnect.patch at the end of the file. In the terminal, run cd networkmanagement dpkg-buildpackage -us -uc cd .. sudo dpkg -i *.deb This will work assuming you don't have any other *.deb files lying around in that directory. Log out and log into KDE, try your OpenConnect connection.
Created attachment 75451 [details] Windows after starting connection. I've applied the patch as you instructed, and now this is what I see when I first try to connect. It seems that it's now remembering the "VPN Host" I used last time. However, then I have to click the connect button (the one in the upper right) before I see the rest of the fields on the window. After clicking connect that button, it looks like the previous screenshot; it remembers "GROUP" and "Username", but it doesn't remember "Password". The "Automatically start connecting next time" still doesn't seem to do anything.
I was just about to create a bug report but this one looks very similar to my issue. I am running Kubuntu 12.10 with the exact same plasma nm: Version 0.9.0.5 (nm09 20120930). I have configured a vpn connection using openconnect and it works fine as far as network connectivity is concerned. However, when I select the VPN from the network manager tray applet it always pops up the attached dialog (see openconnect.png) and I have to type in my password. It does remember the VPN host, the GROUP and the username, just not the password. I have previously used vpnc rather than openconnect and that saved my password. Is it possible to fix the openconnect module to save the password as well ?
Created attachment 75733 [details] openconnect.png (connection dialog with password prompt)
Sorry for the delay, real life has been crazy lately... Anyway, are you certain that the "automatically start connect next time" checkbox is not doing anything? It works for me, however I only have one server in the selection box. It shoud work like this: First time, no login box, you click on the connect button. You check the autoconnect box, type in your password and log in. Upon the next connection, it should display the login form (that the form was displayed at once before the patch was actually a bug). I also looked into saving the password, unfortunately it is not possible to do it securely, the password would be saved in clear text in /etc/NetworkManager/system-connections/connectionname. The technical explanation: Connection settings can not be altered by a reply from a secret agent (this is why all settings set by the OpenConnect login dialog are being put into the secret map, since only it can be permanently altered), however the secret flags needed in order to store the secrets by the user agent must be in the settings map and would have to be set by the auth widget upon user interaction, since the form ids can not be known in advance (when the connection is created).
I can try it again later, but I'm confident that my previous description was accurate. I suppose I can make a screencast if that would help. However, if the password can't be saved, then this problem can't really be fixed. Maybe you can save me a mouse click or two, but entering my password is the larger inconvenience and automatic connection is impossible. From a user perspective, it sounds fishy that a wifi password can be saved (allowing true automatic connection) but a VPN password cannot. However, I'll take your word for it.
The difference between WiFi (or VPNC) and OpenConnect is that WiFi (or VPNC) is standardized, you know in advance (upon connection creation) if and what kind of password you need. OpenConnect, however, receives information on what input fields to display from the VPN server on the first creation attempt, and this information is not constrained in any way, so you could even have multiple passwords or no password at all. This is not known at connection creation time, and might even change over the lifetime of the connection, e.g. the VPN server could be reconfigured.
Got it, the information needs to be known at connection creation time. Two thoughts: 1) Once the first connection has taken place, this information is now known. Could a new connection then automatically be created with that information? Then, the old connection could be deleted. The space of possible inputs that the server wants may be vast, but if the inputs can be boiled down to a sequence of strings, then I imagine kwallet can store it. 2) The user may well know in advance if and what kind of password is needed, and there may be common use cases. E.g. -- looking at our pictures -- it seems that both Glenn and I need to provide the same pieces of information. Perhaps several common cases could be covered? Other cases could be handled the way they're handled now. If the VPN server is reconfigured, then the client probably will need to be reconfigured too; that's perfectly reasonable.
These are all hacks and special cases, which I would like to avoid if possible. I have asked the NetworkManager developers about a better solution [1], let's see what they write first. Did you get to test the autoconnect checkbox yet? [1] https://mail.gnome.org/archives/networkmanager-list/2013-January/msg00020.html
Ilia, I get the impression that you are not using the KDE wallet to store the connection details - is that correct ? I can't imagine ever wanting my password stored in plain text. If you used the KDE wallet would the issue of the dialog box not being able to save the passwords go away ? Like Leon I will always be prompted for the exact same details each time I login. In my case that will be a username and a password. I find it surprising that the username can be remembered but that the password cannot. Could the connection dialog save which fields are required on first connection (i.e. username and password) but not the values typed in. Then the tray applet could provide text boxes for those fields on the next connection before the connection dialog is invoked. When the connection dialog is invoked it could then check if the same fields are being requested and if so could get the values from the tray applet. And hopefully the tray applet would be able to save those values even if the connection dialog can't. Would that work ?
You're right, the "Automatically start connection next time" checkbox is working as you describe; I'm not sure what's different than last time. Once, it got stuck in the "Contacting host, please wait" stage, and the cancel button didn't seem to do anything, but that problem may well have been due to a flaky connection on my end. With regards to 1, you're right that I phrased it as a hack, but phrase it a little differently and it's a setup wizard. They're not the cleanest solutions out there, but there's nothing hackish about them either; they're a tool to use when configuration is too complicated to do automatically.
Created attachment 76295 [details] Stuck on "Contacting host, please wait..."
Created attachment 76296 [details] "Automatically start connection last time" working as advertised.
Finally I understand why I have to re-enter the VPN password every time I connect. If you need someone to test a patch, I can easily do that. I could also try working on a patch myself in the next holidays, but of course that'd require some acceptable way to solve this issue in the first place. What I do not understand: If NM can not store these dynamic properties, why can it store the username? Also, why is KWallet opened at all when connecting using OpenConnect (and the connection attempt actually fails if I hit "Cacnel" there, so something requires KWallet)? Regarding this "Automatically connect to server" checkbox: It makes no difference here. No matter whether I have it checked or not, the widget will automatically connect to the server and cretae the appropriate widgets. And even if it worked as described above, maybe the wording should be changed... actually, is there any reason not to always automatically connect, and just get rid of the checkbox? IMHO that's the expected behaviour, after all, I just clicked on the VPN name to connect to it.
plasma-widget-networkmanagement doesn't remember VPN PPTP password in Kubuntu 13.10. I downgrade to old version plasma-widget-networkmanagement and delete file plasma-nm Option save doesnt work, samtimes work, samtimes no but doesn't remember password. I dont use KWallet program. http://forum.ubuntu-rs.org/Thread-network-manager-vpn?pid=226999#pid226999
I am also experiencing the same issue in Kubuntu 14.04.1 / KDE 4.13.3. bug #332057 might be a duplicate.
*** Bug 332057 has been marked as a duplicate of this bug. ***
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 339296, 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 339296, 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 339296, 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 339296, bug 334474 M +11 -1 kded/secretagent.cpp http://commits.kde.org/plasma-nm/20e8f2d6924b90492074221a2c3d971eb9c52112
Git commit ae412aa60e400f9f53c59e42def8b78226b21961 by Jan Grulich. Committed on 13/01/2015 at 15:27. Pushed by grulich into branch 'master'. Make NM to store Openconnect secrets into KWallet REVIEW:122012 Related: bug 334474 M +36 -0 kded/secretagent.cpp M +13 -2 vpn/openconnect/openconnectauth.cpp M +7 -0 vpn/openconnect/openconnectwidget.cpp http://commits.kde.org/plasma-nm/ae412aa60e400f9f53c59e42def8b78226b21961
Git commit 35effa11540bbec8b6d13aa520656b270b31728e by Jan Grulich. Committed on 13/01/2015 at 15:27. Pushed by grulich into branch '0.9.3'. Make NM to store Openconnect secrets into KWallet REVIEW:122012 Related: bug 334474 M +36 -0 kded/secretagent.cpp M +12 -2 vpn/openconnect/openconnectauth.cpp M +7 -0 vpn/openconnect/openconnectwidget.cpp http://commits.kde.org/plasma-nm/35effa11540bbec8b6d13aa520656b270b31728e
This should be conditional. Some companies' security policies forbid saving the password. In the GNOME auth-dialog we have a checkbox to enable/disable the saving of passwords. The setting is stored in a "save_passwords" secret.
Git commit a2ab031e759c1c08c027b06aa1655cd1026f839e by Jan Grulich. Committed on 19/01/2015 at 13:15. Pushed by grulich into branch 'master'. Make storing openconnect secrets optional M +5 -1 kded/secretagent.cpp M +5 -0 vpn/openconnect/openconnectauth.cpp M +27 -2 vpn/openconnect/openconnectauth.ui http://commits.kde.org/plasma-nm/a2ab031e759c1c08c027b06aa1655cd1026f839e
Git commit fb0a729cf712be5eab96a7e957e85a3d2c02bf7d by Jan Grulich. Committed on 19/01/2015 at 13:15. Pushed by grulich into branch '0.9.3'. Make storing openconnect secrets optional M +6 -1 kded/secretagent.cpp M +5 -0 vpn/openconnect/openconnectauth.cpp M +27 -2 vpn/openconnect/openconnectauth.ui http://commits.kde.org/plasma-nm/fb0a729cf712be5eab96a7e957e85a3d2c02bf7d
Git commit cae27f8e6e34f806f83d524b032968b15fde4ea9 by Jan Grulich. Committed on 13/01/2015 at 15:27. Pushed by grulich into branch 'Plasma/5.2'. Make NM to store Openconnect secrets into KWallet REVIEW:122012 Related: bug 334474 M +36 -0 kded/secretagent.cpp M +13 -2 vpn/openconnect/openconnectauth.cpp M +7 -0 vpn/openconnect/openconnectwidget.cpp http://commits.kde.org/plasma-nm/cae27f8e6e34f806f83d524b032968b15fde4ea9
Git commit ed8b83473227beb6b6bd8e95b43f5a9c60091598 by Jan Grulich. Committed on 19/01/2015 at 13:15. Pushed by grulich into branch 'Plasma/5.2'. Make storing openconnect secrets optional M +6 -2 kded/secretagent.cpp M +5 -0 vpn/openconnect/openconnectauth.cpp M +27 -2 vpn/openconnect/openconnectauth.ui http://commits.kde.org/plasma-nm/ed8b83473227beb6b6bd8e95b43f5a9c60091598