After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 606599 - NetworkManager-openconnect plugin fails to load auth dialog
NetworkManager-openconnect plugin fails to load auth dialog
Status: RESOLVED INVALID
Product: NetworkManager
Classification: Platform
Component: VPN: openconnect
git master
Other Linux
: Normal blocker
: ---
Assigned To: Dan Williams
Depends on:
Blocks:
 
 
Reported: 2010-01-11 02:48 UTC by Erik Johnson
Modified: 2010-01-13 20:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Erik Johnson 2010-01-11 02:48:49 UTC
I am not able to get to the authentication dialog. When I try to start a VPN connection, there is a libnotify notification saying that the connection failed because there were no valid VPN secrets. This is also accompanied by an error dialog saying the following:

There was a problem launching the authentication dialog for VPN connection type 'org.freedesktop.NetworkManager.openconnect'. Contact your system administrator.'

The messages log shows the following:

Jan 10 18:59:55 gallifrey NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.openconnect'...
Jan 10 18:59:55 gallifrey NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 2440
Jan 10 18:59:55 gallifrey kernel: vpn0: Disabled Privacy Extensions
Jan 10 18:59:55 gallifrey NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openconnect' just appeared, activating connections
Jan 10 18:59:56 gallifrey NetworkManager: <WARN> get_secrets_cb(): Couldn't get connection secrets: vpn-password-dialog.c.262 (nma_vpn_request_password): couldn't run VPN

I have updated to the git master versions of NetworkManager, nm-applet, and NetworkManager-openconnect, as well as the latest dbus release, but the problem still remains.

The openconnect plugin was built with --disable-static.

Steps to replicate:
1) Configure an openconnect VPN
2) Click the nm-applet icon
3) Select the VPN you created
Comment 1 Erik Johnson 2010-01-11 02:55:31 UTC
This behavior also exists in version 0.7.2. I have not tested it on earlier versions.
Comment 2 Dan Williams 2010-01-11 18:14:34 UTC
Can you paste the contents of /etc/NetworkManager/VPN/nm-openvpn-service.name for me?  It should look something like this:

[VPN Connection]
name=openvpn
service=org.freedesktop.NetworkManager.openvpn
program=/usr/libexec/nm-openvpn-service

[GNOME]
auth-dialog=nm-openvpn-auth-dialog
properties=libnm-openvpn-properties


Then check /usr/libexec/ (or wherever you configured LIBEXECDIR when running configure during the build, or your platform's normal libexecdir) for nm-openvpn-auth-dialog.
Comment 3 Ionut Biru 2010-01-12 01:19:03 UTC
[VPN Connection]
name=openconnect
service=org.freedesktop.NetworkManager.openconnect
program=/usr/lib/networkmanager/nm-openconnect-service

[GNOME]
auth-dialog=nm-openconnect-auth-dialog
properties=libnm-openconnect-properties


/usr/lib/openconnect/nm-openconnect-auth-dialog. that seems to be a packaging bug.
Comment 4 Erik Johnson 2010-01-12 02:43:37 UTC
Yep, I symlinked the nm-openconnect-auth-dialog within the libexecdir (/usr/lib/networkmanager/) and it's working now. Thanks, Dan, for helping figure this out. This can be closed.
Comment 5 Dan Williams 2010-01-13 20:41:15 UTC
ok, thanks for the report.

nm-applet is set to look in LIBEXECDIR, so you need to ensure that when you configure both NetworkManager-openconnect and network-manager-applet, that you give both of these the same LIBEXECDIR at configure-time during the build.
Comment 6 Erik Johnson 2010-01-13 20:51:35 UTC
Yeah, they both had the same libexecdir but the auth dialog binary was installed to a different directory from the libexecdir. Thanks for helping clear this up.