GNOME Bugzilla – Bug 679212
NetworkManager VPN secrets: NetworkAgent internal error
Last modified: 2013-04-20 05:55:17 UTC
Configure a NetworkManager VPN connection to "always ask" for a password. * Expected behavior After turning the VPN on, the user is prompted for a password, which is used for the VPN connection. * Actual result The connection attempt fails immediately, without ever prompting the user for a password. NetworkManager logs the following error when interacting with Shell.NetworkAgent: NetworkManager[21906]: <debug> [1341104030.873812] [nm-agent-manager.c:699] get_done_cb(): (:1.46/org.gnome.Shell.NetworkAgent/1000) agent failed secrets request 0x26ad0e0/vpn: (32) An internal error occurred while processing the request. Complete logs are pasted below. * Notes - The same mechanism is working fine with wifi, but the VPN code path seems to be handling secret agents a bit differently. Below are logs for this case as well. But the NetworkManager code is too confusing for me to tell what the differences are. Is there any documentation or example code on how interaction with secrets agents should work in gnome-shell? - The VPN connection can be established successfully if the password is entered and saved directly in the NetworkManager configuration. I am using this as a workaround right now. * Arch Linux package versions gnome-shell 3.4.1-3 networkmanager 0.9.4.0-6 * NetworkManager logs Here is the bad case (VPN): <info> Starting VPN service 'pptp'... <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 21918 <info> VPN service 'pptp' appeared; activating connections <debug> [1341104030.809422] [nm-vpn-connection.c:971] get_secrets(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/superfreevpn) requesting VPN secrets pass #1 <debug> [1341104030.809515] [nm-agent-manager.c:1059] nm_agent_manager_get_secrets(): Secrets requested for connection /org/freedesktop/NetworkManager/Settings/1 (vpn) <debug> [1341104030.809545] [nm-settings-connection.c:864] nm_settings_connection_get_secrets(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:1) secrets requested flags 0x80000000 hint '(null)' <debug> [1341104030.809885] [nm-agent-manager.c:974] get_start(): (0x26ad0e0/vpn) system settings secrets sufficient <debug> [1341104030.809901] [nm-settings-connection.c:721] agent_secrets_done_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:1) existing secrets returned <debug> [1341104030.809908] [nm-settings-connection.c:727] agent_secrets_done_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:1) secrets request completed <debug> [1341104030.810388] [nm-settings-connection.c:767] agent_secrets_done_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:1) new agent secrets processed <debug> [1341104030.810403] [nm-vpn-connection.c:939] get_secrets_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/superfreevpn) asking service if additional secrets are required <debug> [1341104030.812417] [nm-vpn-connection.c:901] plugin_need_secrets_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/superfreevpn) service indicated additional secrets required <debug> [1341104030.812452] [nm-vpn-connection.c:971] get_secrets(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/superfreevpn) requesting VPN secrets pass #2 <debug> [1341104030.812550] [nm-agent-manager.c:1059] nm_agent_manager_get_secrets(): Secrets requested for connection /org/freedesktop/NetworkManager/Settings/1 (vpn) <debug> [1341104030.812589] [nm-agent-manager.c:578] request_add_agent(): (:1.46/org.gnome.Shell.NetworkAgent/1000) agent allowed for secrets request 0x26ad0e0/vpn <debug> [1341104030.812613] [nm-settings-connection.c:864] nm_settings_connection_get_secrets(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:2) secrets requested flags 0x0 hint '(null)' <debug> [1341104030.812859] [nm-agent-manager.c:980] get_start(): (0x26ad0e0/vpn) system settings secrets insufficient, asking agents <debug> [1341104030.812875] [nm-agent-manager.c:653] next_generic(): (:1.46/org.gnome.Shell.NetworkAgent/1000) agent getting secrets for request 0x26ad0e0/vpn <debug> [1341104030.812885] [nm-agent-manager.c:935] get_next_cb(): (0x26ad0e0/vpn) requesting user-owned secrets from agent :1.46 <debug> [1341104030.839234] [nm-agent-manager.c:720] get_done_cb(): (:1.46/org.gnome.Shell.NetworkAgent/1000) agent returned secrets for request 0x26ad0e0/vpn <debug> [1341104030.839416] [nm-settings-connection.c:684] agent_secrets_done_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:2) secrets returned from agent :1.46 <debug> [1341104030.839430] [nm-settings-connection.c:727] agent_secrets_done_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:2) secrets request completed <debug> [1341104030.840035] [nm-settings-connection.c:767] agent_secrets_done_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:2) new agent secrets processed <debug> [1341104030.840053] [nm-vpn-connection.c:939] get_secrets_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/superfreevpn) asking service if additional secrets are required <debug> [1341104030.841446] [nm-vpn-connection.c:901] plugin_need_secrets_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/superfreevpn) service indicated additional secrets required <debug> [1341104030.841479] [nm-vpn-connection.c:971] get_secrets(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/superfreevpn) requesting VPN secrets pass #3 <debug> [1341104030.841555] [nm-agent-manager.c:1059] nm_agent_manager_get_secrets(): Secrets requested for connection /org/freedesktop/NetworkManager/Settings/1 (vpn) <debug> [1341104030.841585] [nm-agent-manager.c:578] request_add_agent(): (:1.46/org.gnome.Shell.NetworkAgent/1000) agent allowed for secrets request 0x26ad0e0/vpn <debug> [1341104030.841596] [nm-settings-connection.c:864] nm_settings_connection_get_secrets(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:3) secrets requested flags 0x1 hint '(null)' <debug> [1341104030.841787] [nm-agent-manager.c:980] get_start(): (0x26ad0e0/vpn) system settings secrets insufficient, asking agents <debug> [1341104030.841801] [nm-agent-manager.c:653] next_generic(): (:1.46/org.gnome.Shell.NetworkAgent/1000) agent getting secrets for request 0x26ad0e0/vpn <debug> [1341104030.841807] [nm-agent-manager.c:913] get_next_cb(): (0x26ad0e0/vpn) request has system secrets; checking agent :1.46 for MODIFY <debug> [1341104030.850570] [nm-agent-manager.c:844] get_agent_modify_auth_cb(): (0x26ad0e0/vpn) agent MODIFY check result 1 <debug> [1341104030.873812] [nm-agent-manager.c:699] get_done_cb(): (:1.46/org.gnome.Shell.NetworkAgent/1000) agent failed secrets request 0x26ad0e0/vpn: (32) An internal error occurred while processing the request. <debug> [1341104030.873914] [nm-settings-connection.c:663] agent_secrets_done_cb(): (c75f0cf3-25a3-41e7-b73a-60e8f136322d/vpn:3) secrets request error: (6) No agents were available for this request. <error> [1341104030.873939] [nm-vpn-connection.c:934] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request. And here is the good case (WIFI): <debug> [1341106243.338050] [nm-agent-manager.c:578] request_add_agent(): (:1.113/org.gnome.Shell.NetworkAgent/1000) agent allowed for secrets request 0xb5a180/802-11-wireless-security <debug> [1341106243.338170] [nm-agent-manager.c:653] next_generic(): (:1.113/org.gnome.Shell.NetworkAgent/1000) agent getting secrets for request 0xb5a180/802-11-wireless-security <debug> [1341106243.338444] [nm-agent-manager.c:913] get_next_cb(): (0xb5a180/802-11-wireless-security) request has system secrets; checking agent :1.113 for MODIFY <debug> [1341106243.344135] [nm-agent-manager.c:1134] save_done_cb(): (:1.113/org.gnome.Shell.NetworkAgent/1000) agent saved secrets for request 0xb5db80/(null) <debug> [1341106243.345148] [nm-agent-manager.c:844] get_agent_modify_auth_cb(): (0xb5a180/802-11-wireless-security) agent MODIFY check result 1 <debug> [1341106246.51537] [nm-agent-manager.c:720] get_done_cb(): (:1.113/org.gnome.Shell.NetworkAgent/1000) agent returned secrets for request 0xb5a180/802-11-wireless-security
Which VPN plugin is this? Openconnect or openvpn/pptp/openswan/vpnc? (They use a slightly different communication protocol). Also, do you see anything in the session logs, such as JS errors? (~/.xsession-errors or ~/.cache/gdm/session.log, depending on your gdm version)
This is for networkmanager-pptp version 0.9.4.0. Indeed, there are JS errors in .xsession-errors: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x2a00003 (Editing su) Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed. JS LOG: Error 'VPN plugin at /usr/lib/gnome-shell/nm-pptp-auth-dialog is not executable' while processing VPN keyfile '/etc/NetworkManager/VPN/nm-pptp-service.name' JS LOG: Error 'VPN plugin at /usr/lib/gnome-shell/nm-openconnect-auth-dialog is not executable' while processing VPN keyfile '/etc/NetworkManager/VPN/nm-openconnect-service.name' JS LOG: Error 'VPN plugin at /usr/lib/gnome-shell/nm-vpnc-auth-dialog is not executable' while processing VPN keyfile '/etc/NetworkManager/VPN/nm-vpnc-service.name' JS LOG: Invalid VPN service type (cannot find authentication binary) The missing executables are in /usr/lib/networkmanager, since Arch Linux installs it with ./configure --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/lib/networkmanager \ --disable-static make install while the gnome-shell package uses PYTHON=/usr/bin/python2 ./configure --prefix=/usr --sysconfdir=/etc \ --libexecdir=/usr/lib/gnome-shell \ --localstatedir=/var --disable-static \ --disable-schemas-compile make make install It seems that gnome-shell searches its own libexecdir instead of the plugin's for its binaries. The missing binary is configured in the auth-diag field of /etc/NetworkManager/VPN/nm-pptp-service.name. The same config file already uses an absolute path for @LIBEXECDIR@/nm-pptp-service, so I have patched networkmanager-pptp to do the same for auth-diag. I also had to patch gnome-shell to recognize the absolute path. This fixes the described issue with pptp. Note that other networkmanager plugins probably have to be patched as well. The gnome-shell patch is backwards compatible, but the networkmanager-pptp will break unpatched gnome-shell setups. So, if this is acceptable, I suggest we apply the gnome-shell patch as soon as possible, and the networkmanager-pptp patch after same grace period?
Created attachment 217777 [details] [review] gnome-shell patch
Created attachment 217778 [details] [review] networkmanager-pptp patch
Review of attachment 217777 [details] [review]: While I could consider this weird libexecdir setting a distribution problem, this patch definitely makes sense. Please also open a new bug for network-manager-pptp, so that the other patch will be reviewed properly. (Also, tell me if you don't have commit access)
I created https://bugzilla.gnome.org/show_bug.cgi?id=679225 for networkmanager-pptp with the patch attached. I do not have commit access. Regarding the libexecdir setting I can try to make an argument with the Arch Linux maintainers. It seems likely that other things will break as well if this is not supported. So, would you recommend using the default setting /usr/libexec for both gnome-shell and networkmanager?
Looks like not using /usr/libexec is a rule for Arch Packaging: "Avoid using /usr/libexec/ for anything. Use /usr/lib/${pkgname}/ instead." https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_etiquette
Comment on attachment 217777 [details] [review] gnome-shell patch I pushed your patch. This bug can be closed when the associated NM bug is resolved.
Fixed in master *** This bug has been marked as a duplicate of bug 694768 ***