Can’t connect to VPN from GNOME Shell

I can't reproduce this with -vpnc or -pptp, so we'll assume it's specific to -openconnect.

Can you make sure that at least libnm-gtk-0/libnm-gtk-common are installed on your system, and which version they're at?

Yeah, I have these packages installed:

gir1.2-networkmanager-1.0 0.9.4.0-0ubuntu3
libnm-glib-vpn1 0.9.4.0-0ubuntu3
libnm-glib4 0.9.4.0-0ubuntu3
libnm-util2 0.9.4.0-0ubuntu3
network-manager 0.9.4.0-0ubuntu3

libnm-gtk-common 0.9.4.1-0ubuntu2
libnm-gtk0 0.9.4.1-0ubuntu2
network-manager-gnome 0.9.4.1-0ubuntu2

libopenconnect1 3.15-0ubuntu2
openconnect 3.15-0ubuntu2

network-manager-openconnect 0.9.4.0-0ubuntu1
network-manager-openconnect-gnome 0.9.4.0-0ubuntu1

gnome-shell 3.4.1-0ubuntu2
gnome-shell-common 3.4.1-0ubuntu2

I have the same problem -- after performing an update today my VPN (vpnc based) fails to prompt me for a password. I get the same error in my .xsession-errors as reported. I also see in my syslog when trying to start the VPN:

Apr 19 15:30:27 cft-dv7 NetworkManager[1281]: <error> [1334863827.142391] [nm-vpn-connection.c:934] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.

I do have libnm-gtk-0 and libnm-gtk-common 0.9.4.1-0ubuntu2 installed.

I just re-installed libnm-gtk0 and libnm-gtk-common via synaptic. logged-out-back-in and now am being prompted for my VPN credentials.

Is nm-applet running?

My system is fully updated and all the vpn plugins I'm trying work just fine, there has to be something else at play..

Huh. While constructing the above list, I removed some -dev packages on a whim:

libnm-glib-dev 0.9.4.0-0ubuntu3
network-manager-dev 0.9.4.0-0ubuntu3
libnm-util-dev 0.9.4.0-0ubuntu3
libopenconnect-dev 3.15-0ubuntu2

And then when I logged out and logged in, my VPN started working in GNOME Shell again. Then I played with reinstalling and uninstalling them a few times; for a while the problem seemed to be correlated with network-manager-dev being installed, but now I have them all installed again and the VPN works anyway.

So, uh, yeah. I guess this can be closed for now.

I’m still a little concerned, though, since the intent of the code that was generated the “Stopping registered applet secret agent” error message is clearly to disable the agent when GNOME Shell ≥ 3.4 is running. That message no longer appears for me. Maybe the only reason my VPN works now is that I managed to trigger some kind race condition that prevents nm-applet from detecting GNOME Shell?

Closing as Invalid since the resolution is unclear.

This still happens occasionally for me on login, but I figured out that I can reproduce it deterministically if I restart nm-applet while gnome-shell is running:

$ pkill nm-applet
$ nm-applet &
[1] 9146
** Message: applet now removed from the notification area
** Message: applet now embedded in the notification area
** Message: applet now removed from the notification area
** Message: Stopping registered applet secret agent because GNOME Shell is running
** Message: using fallback from indicator to GtkStatusIcon
** Message: applet now embedded in the notification area

Now the VPN doesn’t work, and gnome-shell logs this error:

      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-pptp-auth-dialog is not executable' while processing VPN keyfile '/etc/NetworkManager/VPN/nm-pptp-service.name'
      JS LOG: Invalid VPN service type (cannot find authentication binary)

$ pkill gnome-shell
$ pkill nm-applet
$ nm-applet &
[1] 9782
** Message: applet now removed from the notification area
** Message: using fallback from indicator to GtkStatusIcon
$ gnome-shell &

Now when I try to connect to the VPN, gnome-shell logs the same error(!), but now nm-applet takes over and lets me log in and connect.

I filed bug 990074 for gnome-shell looking in the wrong directory for VPN plugins. So the remaining bug here is that nm-applet should listen for gnome-shell starting or stopping instead of just checking once at startup.

Status changed to 'Confirmed' because the bug affects multiple users.

I have the same error, using Arch Linux.

Same bug here, with Gnome Shell, vpnc and Pangolin. I can't get a password prompt and I get this error in the logs:

May 2 09:33:32 atlantis NetworkManager[1384]: <error> [1335944012.928378] [nm-vpn-connection.c:934] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.

Same error for me

NetworkManager[1059]: <error> [1336371536.323900] [nm-vpn-connection.c:934] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.

I can confirm that the trick from Anders Kaseorg (anders-kaseorg) #10 is working for me.

The problem does not appear in unity, so it is related to gnome-shell only.

I have this same exact problem and I can't work from home because of it. This is a high priority for me...not sure why it's listed as low.

May 11 08:06:08 localhost NetworkManager[1758]: <info> VPN service 'openvpn' appeared; activating connections
May 11 08:06:08 localhost NetworkManager[1758]: <error> [1336748768.328562] [nm-vpn-connection.c:934] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.
May 11 08:06:13 localhost NetworkManager[1758]: <info> VPN service 'openvpn' disappeared

It seems like this defect is a recurring issue with Ubuntu devs and they keep breaking the same problem.

https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/863120
https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/824255

I can also confirm that the trick in comment #10 is working for me.

I have solved this issue on ARCHLINUX creating an symlink:

sudo ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/nm-vpnc-auth-dialog

I confirm that d1g1t's trick worked fine on Arch Linux for me as well. Thanks!

Seems like http://git.gnome.org/browse/network-manager-applet/commit/?id=0c997a95d5b82ea6733e001478db1e2490b49575 might help a lot here; I'll see about applying this as a SRU to Precise.

Mathieu: I’m worried that fixing nm-applet’s gnome-shell detection code, without first fixing gnome-shell’s location to look for NM plugins (which should be /usr/lib/network-manager instead of /usr/lib/gnome-shell), will cause this to break all the time, instead of just when gnome-shell doesn’t lose the startup race.

(Er, of course I mean /usr/lib/NetworkManager.)

I am additionally worried that, on my quantal system at least, when I symlink nm-openconnect-auth-dialog into the wrong /usr/lib/gnome-shell location and restart nm-applet while gnome-shell is running, then gnome-shell segfaults in shell_network_agent_set_password() when I connect to a VPN.

So there are probably three bugs here that roughly cancel each other out, and we need to be very careful about what order we fix them in, especially for a precise SRU.

> Mathieu: I’m worried that fixing nm-applet’s gnome-shell detection code, without first
> fixing gnome-shell’s location to look for NM plugins (which should be
> /usr/lib/network-manager instead of /usr/lib/gnome-shell), will cause this to break all
> the time, instead of just when gnome-shell doesn’t lose the startup race.

This appears to be exactly what happened with the upload of network-manager-applet 0.9.6.0~git201207161252.13c6db8-0ubuntu1. Now it’s _always_ impossible to connect to a VPN from gnome-shell, even when nm-applet is started first.

$ nm-applet &

** (nm-applet:29893): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-Uvn8AW90K7: Connection refused
** Message: applet now removed from the notification area
** Message: using fallback from indicator to GtkStatusIcon
$ gnome-shell &

** (gnome-shell:29899): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-Uvn8AW90K7: Connection refused
      JS LOG: Error: Requiring IBus, version none: Typelib file for namespace 'IBus' (any version) not found

** (gnome-shell-calendar-server:29910): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-Uvn8AW90K7: Connection refused
      JS LOG: GNOME Shell started at Wed Jul 18 2012 19:53:08 GMT-0400 (EDT)
** Message: applet now embedded in the notification area
** Message: Stopping applet secret agent because GNOME Shell appeared
$ [try to connect to a VPN]
      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-pptp-auth-dialog is not executable' while processing VPN keyfile '/etc/NetworkManager/VPN/nm-pptp-service.name'
      JS LOG: Invalid VPN service type (cannot find authentication binary)

Will look into why gnome-shell doesn't use the right libexec dir; must simply have been overlooked.

nm-applet and gnome-shell appear to be doing the right thing: gnome-shell adds its own LIBEXECDIR if the path isn't absolute, and nm-applet always strips out the path to use its own LIBEXECDIR (which would be the right one anyway).

I'll look at all the VPN plugins and test if adding the libexecdir as path to the auth-dialog would be sufficient to correctly fix this.

This bug was fixed in the package network-manager-vpnc - 0.9.6~git201207121441.383f3dc-0ubuntu2

---------------
network-manager-vpnc (0.9.6~git201207121441.383f3dc-0ubuntu2) quantal; urgency=low

  * debian/patches/auth-dialog-libexecdir.patch: set libexecdir for the auth
    dialog; so that the dialog can be properly started by GNOME Shell.
    (LP: #985788)
 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 20 Jul 2012 11:15:20 -0400

This bug was fixed in the package network-manager-openconnect - 0.9.5.95-0ubuntu1

---------------
network-manager-openconnect (0.9.5.95-0ubuntu1) quantal; urgency=low

  * New upstream release.
    - Use gnome-keyring for password fields. (LP: #799701)
  * debian/patches/04_fix-hitting-cancel-after-failure.patch,
    debian/patches/02_fix-ignoring-return-value.patch,
    debian/patches/01_implement-proper-cancellation.patch: dropped, these
    patches are included in the 0.9.5.95 release.
  * debian/patches/dont_fail_if_no_ip6_714dea4.patch: don't fail activation
    if there is no IPv6 address passed. Some people still don't have IPv6...
  * debian/control:
    - update Build-Depends to require NM >= 0.9.5.95.
    - add libgnome-keyring-dev to Build-Depends.
  * debian/patches/auth_dialog_libexecdir.patch: specify libexecdir as
    /usr/lib/NetworkManager for the auth dialog to be able to spawn it properly
    in GNOME Shell. (LP: #985788)
 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 20 Jul 2012 16:44:24 -0400

Anders,

Please try the network-manager-openconnect package in Quantal, and let me know if it properly fixes the issue for you :)

This bug was fixed in the package network-manager-pptp - 0.9.6.0-0ubuntu1

---------------
network-manager-pptp (0.9.6.0-0ubuntu1) quantal; urgency=low

  * New upstream release.
  * debian/control: bump Build-Depends for network-manager libs.
  * debian/patches/auth_dialog_libexecdir.patch: specify libexecdir as
    /usr/lib/NetworkManager for the auth dialog to be able to spawn it properly
    in GNOME Shell. (LP: #985788)
 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 08 Aug 2012 17:41:25 -0400

This bug was fixed in the package network-manager-openvpn - 0.9.6.0-0ubuntu2

---------------
network-manager-openvpn (0.9.6.0-0ubuntu2) quantal; urgency=low

  * debian/patches/auth_dialog_libexecdir.patch: specify libexecdir as
    /usr/lib/NetworkManager for the auth dialog to be able to spawn it properly
    in GNOME Shell. (LP: #985788)
 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 10 Aug 2012 14:25:07 -0400

Debian added this patch to gnome-shell 3.4.2, which I guess means you can drop the network-manager vpn plugin patches in raring:

http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-shell/debian/patches/27-nm-libexec-path.patch?view=markup

You could, but keep in mind this patch was added simply to avoid needing to coordinate updating all of the vpn plugins in Debian post-freeze.

https://lists.debian.org/debian-release/2012/07/msg01693.html

I hope/expect that upstream will incorporate the auth_dialog_libexecdir changes into the plugins. There are already open upstream bug reports on this.

The same here, again.
Gnome 3.12
UbuntuGnome 14.04 beta2

Is there a way to fix it?

Hi Mako', instead of commenting on this dormant and resolved bug in an old Ubuntu release, you might want to look at the recently reported #1300097, you might also be affected by that bug. Or if that bug does not apply to you, you might consider reporting a new bug since the problem you are experiencing may not be related to this bug report.

https://bugs.launchpad.net/bugs/1300097

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release