GNOME Bugzilla – Bug 728681
[review] dcbw/auth-refactor: Can't connect to VPN: GLib.KeyFileError
Last modified: 2014-05-01 13:00:26 UTC
After updating to Gnome 3.12 (on arch), I can not connect to VPN anymore. I assume this is a Gnome-Shell bug and not networkmanager, because it appeared directly after update 3.10->3.12. When I try to connect, it will silently fail. Log says: "JS ERROR: error while reading VPN plugin output keyfile: GLib.KeyFileError: Key file does not have group 'VPN Plugin UI'" # journalctl -r Apr 21 22:29:36 packardbell NetworkManager[301]: <error> [1398112176.912508] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request. Apr 21 22:29:36 packardbell gnome-session[680]: VPNRequestHandler<._readStdoutNewStyle/<@resource:///org/gnome/shell/ui/components/networkAgent.js:499 Apr 21 22:29:36 packardbell gnome-session[680]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169 Apr 21 22:29:36 packardbell gnome-session[680]: VPNRequestHandler<._showNewStyleDialog@resource:///org/gnome/shell/ui/components/networkAgent.js:520 Apr 21 22:29:36 packardbell gnome-session[680]: (gnome-shell:775): Gjs-WARNING **: JS ERROR: error while reading VPN plugin output keyfile: GLib.KeyFileError: Key file does not have group 'VPN Plugin UI' Apr 21 22:29:36 packardbell NetworkManager[301]: <info> VPN service 'vpnc' appeared; activating connections Apr 21 22:29:36 packardbell NetworkManager[301]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 1700 Apr 21 22:29:36 packardbell NetworkManager[301]: <info> Starting VPN service 'vpnc'... Deleting the connection in networkmanager and creating a new one does not solve the problem. Tell me if you need any further details.
can confirm that it happens since my upgrade to GNOME 3.12 in Fedora using the COPR repository.
Which vpnc passwords are marked "Saved" in the configuration for the VPN connection? Are any marked "always ask" or "not required"?
When setting the password to "always ask" it works here with "saved" I see the same bug.
can confirm that when any of the passwords is set to "always ask", it works. If both are to "saved", it doesn't. I didn't test the "not required" case because my VPN requires both passwords ;)
The cause looks like a combination of two things: 1) new GNOME Shell doesn't correctly handle the VPN plugin passing back nothing, which can happen if both passwords are saved, and is valid in some cases if both passwords are saved in the system 2) NetworkManager-vpnc *should* always pass back something to GNOME Shell, even if both passwords are saved. It was not handling this case correctly, which is a bug that appears to have existed since the original external-ui-mode patches in 2011. ------ I've pushed the dcbw/auth-refactor branch of network-manager-vpnc to fix this issue. Any testing would be appreciated. I don't believe that GNOME Shell needs any changes at this time. https://git.gnome.org/browse/network-manager-vpnc/log/?h=dcbw/auth-refactor For Fedora users (either rawhide or F20) you can use the following scratch build of this upstream branch: http://koji.fedoraproject.org/koji/taskinfo?taskID=6767238
(In reply to comment #5) > The cause looks like a combination of two things: > > 1) new GNOME Shell doesn't correctly handle the VPN plugin passing back > nothing, which can happen if both passwords are saved, and is valid in some > cases if both passwords are saved in the system > > 2) NetworkManager-vpnc *should* always pass back something to GNOME Shell, even > if both passwords are saved. It was not handling this case correctly, which is > a bug that appears to have existed since the original external-ui-mode patches > in 2011. > > ------ > > I've pushed the dcbw/auth-refactor branch of network-manager-vpnc to fix this > issue. Any testing would be appreciated. I don't believe that GNOME Shell > needs any changes at this time. > > https://git.gnome.org/browse/network-manager-vpnc/log/?h=dcbw/auth-refactor > > For Fedora users (either rawhide or F20) you can use the following scratch > build of this upstream branch: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6767238 Yes I can confirm that this build fixes it for me.
Created attachment 274929 [details] [review] networkAgent: Handle empty vpn 'keyfiles' Passing back no data is valid in case both secrets (group and user passwords) are stored. Just confirm the request in that case. --- This should handle case 1) (didn't test it though because I do not have build env set up on my rawhide box)
Created attachment 274930 [details] [review] networkAgent: Handle empty vpn 'keyfiles' Passing back no data is valid in case both secrets (group and user passwords) are stored. Just confirm the request in that case.
can confirm that the build on koji fixes the issue for me as well.
Review of attachment 274930 [details] [review]: looks good to me as an interim fix.
Attachment 274930 [details] pushed as bccbcd8 - networkAgent: Handle empty vpn 'keyfiles' Pushed a tested version with a small change.
Cherrypicked the change into 3.12 as well ... now moving to NetworkManager to get Dan's fixes upstream and then we can closed it.
(In reply to comment #5) > I've pushed the dcbw/auth-refactor branch of network-manager-vpnc to fix this > issue. >+eui_finish (const char *vpn_name, >+ /* Only show an entry for a password if (a) we don't have it, and it's >+ * required, or (b) we're retrying authentication. Obviously don't show >+ * anything if interaction is not allowed. >+ */ that needs some rewriting to make sense in the external-ui case >+std_ask_user (const char *vpn_name, This seems like it would be simpler if you made use of nma_vpn_password_dialog_set_show_password() to hide the user password slot when it wasn't needed, rather than moving the group password into the user password slot in that case. >+get_passwords_required (GHashTable *data, >+ if (hints && g_strv_length (hints)) { >+ for (iter = hints; iter && *iter; iter++) { "iter && *iter" can be just "*iter" since you already know hints != NULL.
Fixed up and repushed.
looks good
merged to git master
*** Bug 728564 has been marked as a duplicate of this bug. ***