[SRU] Virtual private network connection fails after distribution upgrade due to outdated Network Manager configuration files

Bug #1297849 reported by Prem Anand
930
This bug affects 210 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Confirmed
High
Unassigned
network-manager-vpnc
New
Undecided
Unassigned
network-manager-applet (Ubuntu)
Fix Released
Medium
Unassigned
Trusty
Fix Released
Medium
Unassigned
network-manager-openconnect (Ubuntu)
Fix Released
High
Unassigned
Trusty
Confirmed
High
Unassigned
Xenial
Fix Released
High
Unassigned
network-manager-openvpn (Ubuntu)
Triaged
High
Unassigned
Trusty
Confirmed
High
Unassigned
Xenial
Confirmed
High
Unassigned
Yakkety
Confirmed
High
Unassigned
network-manager-vpnc (Ubuntu)
Triaged
High
Unassigned
Trusty
Confirmed
High
Unassigned
Xenial
Confirmed
High
Unassigned
Yakkety
Confirmed
High
Unassigned

Bug Description

[Impact]
* People who are using VPN services (of any kind, using vpnc, openvpn, pptp, etc.

[Test Case]
HOW TO REPRODUCE
1. Upgrade to a newer Ubuntu release.
2. Using the Network Manager application, try to start a virtual private network connection.

EXPECTED BEHAVIOUR
- The connection to complete successfully.

ACTUAL BEHAVIOUR
- The current configuration files, created by a previous network manager installation in the gconf user home folder, makes the application to misbehave; returning a log like this:

[Regression Potential]
May cause Gnome-Shell detection to give up prematurely.

[PPA with a Possible Solution]
Please see the https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1297849/comments/107 on information how to try the PPA with a solution to the bug that has the patch https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1297849/+attachment/4253965/+files/network-manager-applet-1297849.patch applied.

[Additional information]
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Starting VPN service 'vpnc'...
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 24419
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> VPN service 'vpnc' appeared; activating connections
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <error> [1395840211.74057] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Policy set 'blizzard' (wlan0) as default for IPv4 routing and DNS.
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <error> [1395840211.74406] [nm-system.c:1266] nm_system_replace_default_ip6_route(): (wlan0): failed to set IPv6 default route: -7
Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Policy set 'blizzard' (wlan0) as default for IPv6 routing and DNS.
Mar 26 13:23:36 hprem-rmbp NetworkManager[855]: <info> VPN service 'vpnc' disappeared

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: network-manager-vpnc 0.9.8.6-1ubuntu2
Uname: Linux 3.13.0-031300-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Mar 26 13:26:42 2014
InstallationDate: Installed on 2014-01-17 (67 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64+mac (20140115)
SourcePackage: network-manager-vpnc
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Prem Anand (h.prem.anand) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-vpnc (Ubuntu):
status: New → Confirmed
Revision history for this message
E. Lefty Kreouzis (lefty-kreouzis) wrote :

This also affects openvpn VPNs not only vpnc

Apr 19 08:37:26 localhost NetworkManager[975]: message repeated 3 times: [ <warn> nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted]
Apr 19 08:38:21 localhost NetworkManager[975]: SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/tun0, iface: tun0)
Apr 19 08:41:01 localhost NetworkManager[975]: <info> Starting VPN service 'openvpn'...
Apr 19 08:41:01 localhost NetworkManager[975]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 8118
Apr 19 08:41:01 localhost NetworkManager[975]: <info> VPN service 'openvpn' appeared; activating connections
Apr 19 08:41:01 localhost NetworkManager[975]: <error> [1397882461.390343] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Apr 19 08:41:01 localhost NetworkManager[975]: <info> Policy set 'Peter' (wlan0) as default for IPv4 routing and DNS.
Apr 19 08:41:06 localhost NetworkManager[975]: <info> VPN service 'openvpn' disappeared

Same error message: [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.

Revision history for this message
E. Lefty Kreouzis (lefty-kreouzis) wrote :

I created a new login and the VPNC VPN was started properly - this must have something to do with the upgrade and the old network-manager-vpnc and network-manager-openvpn settings.

Where are they kept?

Revision history for this message
E. Lefty Kreouzis (lefty-kreouzis) wrote :

When I log in to the new account and start a VPN after this I can start and stop VPNs even from my old account something doesn't start right

Revision history for this message
Mike Seda (x-mike-z) wrote :

I am also experiencing the following after upgrading from 13.10 to 14.04:
get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.

I can connect via command-line (openvpn --config client.ovpn). However, having VPN client integrated into the GUI is highly desirable - since /etc/resolv.conf manipulation is handled with that method.

Please fix at your earliest convenience.

FYI, this issue seems to be related to Bug #1247682:
https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1247682

Revision history for this message
Mike Seda (x-mike-z) wrote :

I have resolved the issue on my box by installing resolvconf (and it's dependency, ubuntu-minimal).

Revision history for this message
Mike Seda (x-mike-z) wrote :

This bug has just reappeared for me. It seems to have occured after the last 14.04 patch set. I am fully up to date with patches as of right now (2014-05-02 11:20).

Revision history for this message
CUnknown (christiaanunknown) wrote :

It seems that exporting the VPN config with the export button in the edit window of the VPN connection is also broken.
Maybe this is related?

It gives an error 'unknown error'.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-openconnect (Ubuntu):
status: New → Confirmed
Revision history for this message
Mkchan (mkchan) wrote :

I am also seeing this.
I can confirm that vpn works when creating a brand new Unity login user

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-openvpn (Ubuntu):
status: New → Confirmed
Revision history for this message
Babar (babarhaq) wrote :

Same issue on 14.04. In my case a restart mostly fixes it.

Revision history for this message
Anton Anikin (anton-anikin) wrote :

I have the same problem on Ubuntu 14.10

Revision history for this message
Kyle Stevens (kstevens715) wrote :

Also experiencing the same thing on 14.04.

Revision history for this message
Kyle Stevens (kstevens715) wrote :

I was able to work around this bug by deleting the files in ~/.local/share/keyrings and then re-entering the credentials.

Revision history for this message
diabloneo (diabloneo) wrote :

sorry, just misclick. Change type back to 'Public'

information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Brian Hart (hartb-austin) wrote :

Also seeing this on Xubuntu 14.04, upgraded from 13.10.

Restart doesn't fix it. I don't have a keyrings file or directory in ~/.local/share/.

If I right click on nm-applet, then Edit Connections, then select a VPN and click Edit, a small edit panel comes up but remains blank/greyed-out for about a minute or so. Then after about a minute, the edit panel is replaced by larger panel with all the data populated and controls enabled.

Revision history for this message
gnustavo (gnustavo) wrote :

The problem was "solved" for me by renaming the $HOME/.gconf directory and restarting the Gnome session.

I don't know what that directory holds but I haven't noticed any side effect besides the VPN working again.

Revision history for this message
Javierrios (jrios) wrote :

Yesterday I was make upgrade ubuntu 13.10 to Ubuntu 14.04 and now vpn don't work ... And I changed the file $home/.gconf and $home/.local/share and the problem i can't fix ... any idea ?

Revision history for this message
Javierrios (jrios) wrote :

The problem is resolved .. I send the e-mail gnustavo and he send me the step for resolved (Thanks !!!)

The Steps

1) Create new user administrador
2) Loggin with new user
3) delete .gconf into the your $home
4) logout
5) Loggin your user
6) the network-manager vpnc work

Revision history for this message
Stefano Bagnatica (thepisu) wrote :

I confirm that the problem is solved renaming .gconf directory (from terminal mv .gconf gconf-backup), and doing logout and login.

@jrios: there is no need to create another admin user, as your user itself can move / delete its .gconf directory.

Would be good to find why this was needed... as I think that this operation could lose some other configs..

Revision history for this message
Petr Kubánek (petr-kubanek) wrote :

The issue seems to be resolved by the latest Network updates - my VPNs connections were not working yesterday, are back working today. I did not change any settings, I just apply available updates.

Revision history for this message
Olivier Godart (olivier-godart-gmail) wrote :

Actually no. I though it was fixed with the update (it was working), but after a reboot, it's broken again!

Revision history for this message
Petr Kubánek (petr-kubanek) wrote :

It works for me even after reboot.

Revision history for this message
tallien (tallien) wrote :

It is still not working for me. I am using vpnc. None of the updates has made any difference for me. When I click on the VPN profile that I created previously, nothing happens. The connection icon doesn't change, and no connection is made. I am able to edit profiles but not actually make a connection. Deleting .gconf didn't work for me, but I may have messed up when I tried that fix. Will try again and update if it works.

Revision history for this message
tallien (tallien) wrote :

I deleted the .gconf folder, shut down my PC and restarted. I was able to get a VPN connection established. But the Disconnect option for the VPN connection failed to work. I clicked on it and nothing happened. The only way to disconnect from the VPN was to use the main Disconnect option and disconnect from my underlying ethernet connection.

After that, all further attempts to connect to a VPN failed the same way as before (click on connect to VPN, nothing happens). Deleting .gconf again and logging in and out allowed me to connect again, and once again I had to disconnect the ethernet connection in order to stop the VPN connection, and then all further attempts to make VPN connections failed again just like before.

Would anyone happen to know if there is a CLI command for connecting and disconnecting to VPNs via vpnc that could be used until this is fixed?

Revision history for this message
Lal Samuel Varghese (lalsam) wrote :

Just put all your vpn parameters in /etc/vpnc/default.conf and then do "sudo vpnc" to connect and "sudo vpnc-disconnect" to disconnect.

Revision history for this message
tallien (tallien) wrote :

Thanks Lal! I found some more info on what you said at http://wiki.centos.org/HowTos/vpnc and tried it out.
It works, but unfortunately this method does not seem to allow me to access certain functions on the system I need to connect to. Probably due to DNS issues. I found some info on that on the Gentoo wiki and will continue to experiment.
In the meantime the applet controls are still not working. It seems for me they only work the first time after deleting .gconf, and after vpnc is used once and a fresh config file is written, it stops working again. Hopefully there will be a fix for this soon.

Revision history for this message
E. Lefty Kreouzis (lefty-kreouzis) wrote :

I noticed the following - in the login sceen if I wait for the WiFi network connection to be established then once I log in I can start/stop VPN connections

If I log in before the connection is established then I am not allowed to start/stop VPN connections

This is supported by the fact that I have created an extra user login - if I can't start/stop VPN connections with my normal user id, if I switch to the extra login I can start/stop them

Revision history for this message
E. Lefty Kreouzis (lefty-kreouzis) wrote :

Further information -

If I find I can't start a VPN connection and I log out and log in again then VPN connections work again.

There seems to be some kind of race issue between log in and network connectivity. I don't have the first clue on where to look though

Revision history for this message
Francis Avila (francisga) wrote :

This also affected me.

When I attempt to connect to a VPN using the network connection icon in the system try, nothing would happen. (Literally nothing: no error message, no ui changes, no "attempting to connect" icon animation, etc.)

Syslog:

Jul 21 10:38:34 hospitium NetworkManager[784]: <info> Starting VPN service 'vpnc'...
Jul 21 10:38:34 hospitium NetworkManager[784]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 5860
Jul 21 10:38:34 hospitium NetworkManager[784]: <info> VPN service 'vpnc' appeared; activating connections
Jul 21 10:38:34 hospitium NetworkManager[784]: <error> [1405957114.724275] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Jul 21 10:38:34 hospitium NetworkManager[784]: <info> Policy set 'Ethernet DHCP' (eth0) as default for IPv4 routing and DNS.
Jul 21 10:38:40 hospitium NetworkManager[784]: <info> VPN service 'vpnc' disappeared

The minimal workaround I used was this:

1. Delete ~/.gconf/apps/nm-applet/%gconf.xml (file attached).
2. Log out then log back in.

So far the file has not reappeared.

Revision history for this message
James Troup (elmo) wrote :

Seeing the same thing on Ubuntu 14.04 with network-manager-pptp. The workaround in #34 also worked for me too.

Revision history for this message
tallien (tallien) wrote :

Looks like my case is a little more problematic than most other posters on this thread.

Re. #32 I am not using WiFi. However I have tried waiting a long time before logging in just to test this and it makes no difference for me. My ethernet connection is usually up almost instantaneously anyway.

Re. #34, the file reappears for me after each first new use upon logging back in. In order to make it work a second time I have to again delete the file and log out/in again. And disconnecting never works from the menu, even on the first use after login.

Revision history for this message
Benjamin Halbrock (kontakt-bennis-blog) wrote :

Same problem with ubuntu 14.04 and networkmanager-openvpn, but th workaround in #34 doesn't work for me.

If any logs are needed, pls tell me which

Revision history for this message
Stefanotis (stefan-brasse) wrote :

Same problem here. I can successfully connect to VPN Network, but immediatelly after being connected, the network-manager restarts. Workaround #34 had no effect.

Aug 5 16:50:57 stef-notebook openconnect[12306]: Established DTLS connection (using OpenSSL)
Aug 5 16:50:58 stef-notebook NetworkManager[11870]: <info> VPN connection 'Uni Marburg' (IP Config Get) complete.
Aug 5 16:50:58 stef-notebook NetworkManager[11870]: <info> Policy set 'friedlnet' (wlan0) as default for IPv4 routing and DNS.
Aug 5 16:50:58 stef-notebook kernel: [ 6261.956506] NetworkManager[11870]: segfault at 740ddf60 ip 00007f030ff57539 sp 00007fffd71a9db8 error 4 in libdbus-1.so.3.7.6[7f030ff31000+44000]
Aug 5 16:50:58 stef-notebook NetworkManager[12322]: <info> NetworkManager (version 0.9.8.8) is starting...

Revision history for this message
Olivier Godart (olivier-godart-gmail) wrote :

@ #38 : your problem is different

Revision history for this message
adasiko (adasiko256) wrote :

#34

"The minimal workaround I used was this:
1. Delete ~/.gconf/apps/nm-applet/%gconf.xml (file attached).
2. Log out then log back in.
So far the file has not reappeared."

Yes, it's working. But it breaks by itself :(

Revision history for this message
Sean Burlington (sean-practicalweb) wrote :

same problem here after applying latest updates and rebooting this morning, VPN was working on Friday

steps at #40 worked for me - thanks

Revision history for this message
Keith Montgomery (bkeithmontgomery) wrote :

#16 Kyle Stevens (kstevens715) - followed your suggestion by deleting files and re-authenticaing key-rings and it worked right away.

Thank You!
Keith

Revision history for this message
tallien (tallien) wrote :

Just tried #16 again and had the same result as with my other fix attempts - the first attempt to connect to a vpn after deleting the files works, but thereafter the vpn submenu stops responding and clicking on "disconnect" does not produce any result.

I tried using "vpnc-disconnect" in terminal. The response was "no vpnc found running". In the end I tried "sudo service network-manager restart" and this broke the vpn connection. The vpn submenu remained unresponsive after the network manager restart, but the "Edit Connections" menu item at the bottom of the connections menu has continued to work throughout, so it seems the problem is only with the vpn-related parts of the menu.

Also tried this on a clean x64 install (prior tests were on 32-bit) and had the same problem. The 64-bit install had never even been configured with a VPN before. Its VPN submenu was unresponsive right from the beginning when I tried to configure a connection.

Revision history for this message
BelhommeN (con5act) wrote :

Yesterday the daily system update took placem and this morning I had the same issue after reboot this morning.

Steps in #40 worked for me.

Revision history for this message
Andrew Miller (andy-bfloeagle) wrote :

I'm in the same boat. Unfortunately, removing the keyring and gconf files does not resolve this issue for me. One thing that is different though is that the %gconf.xml file _does_ reappear for me after I log out and log back in...

Revision history for this message
Ettienne (ettienneleroux) wrote :

run :
restart dbus to resolve issue when it happens.

Revision history for this message
Jay Ungerland (0-jay) wrote :

#34 worked for me on Ubuntu 14.04. Many thanks!

Revision history for this message
guduba (guzopuwo) wrote :

This is so annoying. My system is affected as well. All I can tell is that VPN is not working anymore.
I'd really like to use coarse language at that point. What the heck is going on.

I CAN connect to the VPN but I CANNOT BROWSE the internet. The connection is there - at least that is what the connection manager tells me. Also I can ping google and so on. But browsing DOES NOT WORK - neither with firefox nor chromium, nor links...

Something went really wrong. The fixes mentioned in ealier post do not solve the problem for me.

Really bad work from the ubuntu devs, really disappointing.

Any Ideas what could cause this and how to fix it?

Revision history for this message
Olivier Godart (olivier-godart-gmail) wrote : Re: [Bug 1297849] Re: VPN Connection fails after last upgrade on 14.04
Download full text (3.3 KiB)

This is not related to this bug.
Check the proxy or MTU (I do have to change the MTU manually (I scripted it
of course) after connecting because the automatic value is wrong. There is
probably another bug open for that - try: ifconfig vpn0 mtu 1200)

On 4 September 2014 21:44, guduba <email address hidden> wrote:

> This is so annoying. My system is affected as well. All I can tell is that
> VPN is not working anymore.
> I'd really like to use coarse language at that point. What the heck is
> going on.
>
> I CAN connect to the VPN but I CANNOT BROWSE the internet. The
> connection is there - at least that is what the connection manager tells
> me. Also I can ping google and so on. But browsing DOES NOT WORK -
> neither with firefox nor chromium, nor links...
>
> Something went really wrong. The fixes mentioned in ealier post do not
> solve the problem for me.
>
> Really bad work from the ubuntu devs, really disappointing.
>
>
> Any Ideas what could cause this and how to fix it?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1297849
>
> Title:
> VPN Connection fails after last upgrade on 14.04
>
> Status in “network-manager-openconnect” package in Ubuntu:
> Confirmed
> Status in “network-manager-openvpn” package in Ubuntu:
> Confirmed
> Status in “network-manager-vpnc” package in Ubuntu:
> Confirmed
>
> Bug description:
> Seeing the following errors on trying to start a vpn connection using
> Network Manager
>
> Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Starting VPN
> service 'vpnc'...
> Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> VPN service
> 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 24419
> Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> VPN service
> 'vpnc' appeared; activating connections
> Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <error>
> [1395840211.74057] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to
> request VPN secrets #2: (6) No agents were available for this request.
> Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Policy set
> 'blizzard' (wlan0) as default for IPv4 routing and DNS.
> Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <error>
> [1395840211.74406] [nm-system.c:1266]
> nm_system_replace_default_ip6_route(): (wlan0): failed to set IPv6 default
> route: -7
> Mar 26 13:23:31 hprem-rmbp NetworkManager[855]: <info> Policy set
> 'blizzard' (wlan0) as default for IPv6 routing and DNS.
> Mar 26 13:23:36 hprem-rmbp NetworkManager[855]: <info> VPN service
> 'vpnc' disappeared
>
> ProblemType: Bug
> DistroRelease: Ubuntu 14.04
> Package: network-manager-vpnc 0.9.8.6-1ubuntu2
> Uname: Linux 3.13.0-031300-generic x86_64
> NonfreeKernelModules: wl
> ApportVersion: 2.13.3-0ubuntu1
> Architecture: amd64
> CurrentDesktop: Unity
> Date: Wed Mar 26 13:26:42 2014
> InstallationDate: Installed on 2014-01-17 (67 days ago)
> InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64+mac
> (20140115)
> SourcePackage: network-manager-vpnc
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about...

Read more...

Revision history for this message
Walter Méndez (waltmenz) wrote : Re: VPN Connection fails after last upgrade on 14.04

#16 worked for me, fresh new install of 14.04.
I try #34 first and did not work.

Revision history for this message
Dima Ryazanov (dima-gmail) wrote :

I just upgraded to 14.10 - and VPN stopped working again.

Running "openconnect" manually works as before.

Changed in network-manager-vpnc (Ubuntu):
importance: Undecided → High
Changed in network-manager-openvpn (Ubuntu):
importance: Undecided → High
Changed in network-manager-openconnect (Ubuntu):
importance: Undecided → High
Revision history for this message
pallavi (pallavi-bl-o) wrote :

#34 worked for me, thanks much!

Revision history for this message
Elad Lahav (e2lahav) wrote :

Same problem here, on 14.04. I need to resort to the suggestion described by #34 after almost every system restart. Very annoying.

Revision history for this message
Wiktor: Nizio (zap-4) wrote :

Elad Lahav you do not have to delete ~/.gconf/apps/nm-applet/%gconf.xml, just log out and log in (14.10).

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

I'm having this issue with Ubuntu 14.10. I deleted the whole .gconf folder and rebooted. This did not work.

Then I read #54 and simply logging out and back in made it work again.

tags: added: utopic
Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

This remains a problem for me in Ubuntu 14.10.

Each time I boot my computer, I have to login, then logout, and then log back in again, before I can connect via network-manager-vpnc

tags: added: dist-upgrade
summary: - VPN Connection fails after last upgrade on 14.04
+ Virtual private network connection fails due to a misconfiguration in
+ the network manager
summary: - Virtual private network connection fails due to a misconfiguration in
- the network manager
+ Virtual private network connection fails after distribution upgrade due
+ to a misconfigured time-stamp in the network manager
summary: Virtual private network connection fails after distribution upgrade due
- to a misconfigured time-stamp in the network manager
+ to a misconfiguration in the network manager
description: updated
summary: Virtual private network connection fails after distribution upgrade due
- to a misconfiguration in the network manager
+ to outdated network manager configuration files
Changed in hundredpapercuts:
importance: Undecided → High
status: New → Confirmed
status: Confirmed → Triaged
Changed in network-manager-openconnect (Ubuntu):
status: Confirmed → Triaged
Changed in network-manager-openvpn (Ubuntu):
status: Confirmed → Triaged
Changed in network-manager-vpnc (Ubuntu):
status: Confirmed → Triaged
summary: Virtual private network connection fails after distribution upgrade due
- to outdated network manager configuration files
+ to outdated Network Manager configuration files
Revision history for this message
Julien Béti (julien-beti) wrote : Re: Virtual private network connection fails after distribution upgrade due to outdated Network Manager configuration files

I got the issue upgrading from 14.04 to 14.10. In syslog:
----8<--------------------------------------------------------------------
Nov 3 09:15:34 XXX NetworkManager[1121]: <info> Starting VPN service 'openvpn'...
Nov 3 09:15:34 XXX NetworkManager[1121]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 17585
Nov 3 09:15:34 XXX NetworkManager[1121]: <info> VPN service 'openvpn' appeared; activating connections
Nov 3 09:15:34 XXX NetworkManager[1121]: <error> [1415002534.275472] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Nov 3 09:15:34 XXX NetworkManager[1121]: <info> Policy set 'xxx' (wlan0) as default for IPv4 routing and DNS.
Nov 3 09:15:36 XXX wpa_supplicant[1552]: wlan0: CTRL-EVENT-SCAN-STARTED
Nov 3 09:15:39 XXX NetworkManager[1121]: <info> VPN service 'openvpn' disappeared
---->8--------------------------------------------------------------------

I solved this doing that:
~$ mv .local/share/keystore/ .local/share/keystore.bkp

Revision history for this message
Julien Béti (julien-beti) wrote :

Got the issue once more, even after the move described in comment #57
Logging out and then in again solved the issue... Therefore, not sure the move I described in comment #57 really did something relevant...

Revision history for this message
netheril96 (netheril96) wrote :

Why is this bug not even assigned to someone after several month and being classified as "high" priority?

Revision history for this message
Pavel Boldin (pboldin) wrote :

So, here is the details I got from investigating this bug.

The error is that during first start `nm-applet` is not registering itself as a NetworkManager `secrets agent`. This is due to code in function `constructor` of the file `src/applet.c` (nm-applet code) is waiting for a `notify::shell-version` event that is never happens during the first login.

The cause for this is yet to be found out.

Revision history for this message
Pavel Boldin (pboldin) wrote :

I'm attaching a workaround-like bugfix for this bug.

This emits a shell-notify notification even if there was no connection to the `org.gnome.Shell` thus making the `nm-applet` to register itself as a secrets agent.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "network-manager-applet-1297849.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
Audun Gangsto (audun-m) wrote :

I have additional info to this:
I have the same problem, with openvpn and openconnect, I don't get a GUI asking me for the secrets, and this entry appears in syslog:
[nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.

If i save the secrets in the config, it works for those connections not using one-time-passwords (for obvious reasons).

However, I'm using a homedir restored from a working trusty system, and I have this problem.

If i do a fresh install without restoring anything, it works.

I noticed SVN started asking me for a password, leading me to believe some keyring software is broken and network-manager depends on that to ask for secrets.

It makes no sense to use some keyring stuff for asking for passwords which are most likely going to be one-time-passwords, and if the keyring stuff breaks, network-manager should still be able to request secrets the "normal" way.

I'll try to do more research around this, but most likely I won't have much time for this :(

Revision history for this message
Waldmeisda (frank-waldmeisda) wrote :

Same here after upgrading from 14.04 to 14.10.
Workaround to fix this until next reboot
1. ) delete /.gconf/apps/nm-applet/%gconf.xml
2.) Logout (dont reboot) and login.
VPN is working again. But only till next reboot :(

Revision history for this message
Pavel Boldin (pboldin) wrote :

Audun, can you please restart nm-applet with:
$ G_MESSAGES_DEBUG=nm-applet nm-applet

and attach the output somewhere? It should output a string like 'Unable to find ShellVersion' in debug.

Revision history for this message
John Rosauer (john-rosauer) wrote :

I have the same problem after upgrading to 14.10, though with the "openconnect" Cisco VPN.

Revision history for this message
Bojan Cekrlic (bojan-cekrlic) wrote :

Can confirm this in upgrade from 14.04 -> 14.10.

Nov 10 17:19:36 NetworkManager[1095]: <info> Starting VPN service 'openvpn'...
Nov 10 17:19:36 NetworkManager[1095]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 7680
Nov 10 17:19:36 NetworkManager[1095]: <info> VPN service 'openvpn' appeared; activating connections
Nov 10 17:19:36 NetworkManager[1095]: <error> [1415636376.224125] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.

Deleting %gconf.xml has no effect. Reinstalling/purging "network-manager-*" helped once (but then encountered http://askubuntu.com/questions/469783/ubuntu-14-04-cant-connect-to-new-password-protected-wifi-network). Purging/reinstalling brought back this problem.

Revision history for this message
Bojan Cekrlic (bojan-cekrlic) wrote :

Update: As noted in comment #16, deleting ~/.local/share/keyrings seems to fix the issue temporarily.

Revision history for this message
Trafex (trafex) wrote :

This doesn't fix it for me, none of the workarounds work for me.
The only thing that resolves this is logging out and back in, this is what I do every morning, logging in and out twice.

I'm affected by this bug since I upgraded to 14.10, but a colleague of mine has the exact same issue with a fresh 14.10 install.
Is there anything I can do to speed up resolving this bug? I personally think this is the most annoying bug since years of professional Ubuntu use.

Revision history for this message
Pavel Boldin (pboldin) wrote :

Trafex, please do the following to help me realise if my patch is actually fixes the problem (as it does for me):

1. Kill the `nm-applet` from the shell:
$ killall nm-applet
2. Start nm-applet anew with the debug options specified above:
$ G_MESSAGES_DEBUG=nm-applet nm-applet > nmapplet.log 2>&1
3. Try to connect to a VPN using the `nm-applet` menu.
4. Attach the `nmapplet.log` file here.

Revision history for this message
tallien (tallien) wrote :

I may be in the same situation as Trafex since none of the solutions posted here have worked for me. Maybe we have a slightly different issue. I tried the steps described by Pavel in #70. I was not able to proceed past step 2, as the nm-applet menu never reappeared after I killed it. I had to log out and log back in to get it back. Here are the contents of nmapplet.log - pasting it directly here since it was very short:

(nm-applet:6279): nm-applet-DEBUG: applet now removed from the notification area
(nm-applet:6279): nm-applet-DEBUG: gnome-shell is not running, registering secret agent
(nm-applet:6279): nm-applet-DEBUG: old state indicates that this was not a disconnect 0
(nm-applet:6279): nm-applet-DEBUG: foo_client_state_changed_cb
nm-applet-Message: using fallback from indicator to GtkStatusIcon
(nm-applet:6279): nm-applet-DEBUG: status_icon_size_changed_cb(): status icon size 16 requested

At this point I had waited a few minutes and the applet never came back, so I ctrl-c'd to stop the process, and then logged out and logged back in. When I logged back in I found a bit more had been added to the log:

nm-applet-Message: PID 0 (we are 6279) sent signal 2, shutting down...
g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
nm-applet-Message: PID 6279 (we are 6279) sent signal 15, shutting down...
(nm-applet:6279): GLib-CRITICAL **: Source ID 87 was not found when attempting to remove it
(nm-applet:6279): nm-applet-DEBUG: destroying secret agent

That's where it stopped. I have attached the full log to this post.

In the meantime, I have been getting on my vpn by connecting and disconnecting via the terminal. It seems to work fine for me when I do it via the terminal, so I figured the problem was with the applet.

Revision history for this message
Pavel Boldin (pboldin) wrote :

tallien,

Yes, you are right that the bug you experience is a different one.

Anyway it would help if you can enable the debug for the NetworkManager itself and attach the resulting log?

To do so, please do the following:
1. Enable the `debug` syslog output. Find and edit the `/etc/rsyslog.d/50-default.conf` file uncommenting the lines:

*.=debug;*.=info;*.=notice;*.=warn;\
       auth,authpriv.none;\
       news.none;mail.none -/var/log/debug

2. Enable the NetworkManager debug: add the following lines to the `/etc/NetworkManager/NetworkManager.conf` file:

[logging]
level=DEBUG

3. Restart (or reload) the NetworkManager:
$ sudo restart network-manager

4. Make a single attempt to connect to the VPN and then attach the resulting log here, removing all the viable information.

Revision history for this message
tallien (tallien) wrote :

Thanks Pavel! Not sure if I did this correctly. I could not find lines in my 50-default.conf that were exactly the same as what you posted above, so I just copied and pasted your example above into my conf file instead. Hope that was ok.

When I restarted network-manager the applet went away and came back correctly. When I tried to connect to the VPN nothing happened. The debug log is completely empty. I tried restarting and connecting a second time, again nothing and the log remains empty (literally 0 bytes).

Did I look in the right place? Is /var/log/debug the correct place to look for the file?

The feeling I get when I click on the VPN link in my applet submenu is that the click is not registering on the system. Something like an empty a href link tag in an html page. The link simply doesn't respond when it is clicked on.

As I mentioned previously, VPN connects fine when I do it from the terminal, so I wonder if there is something wrong or missing in the applet's VPN submenu.

Revision history for this message
Pavel Boldin (pboldin) wrote :

tallien, sorry I forgot to say you to restart rsyslog:

$ sudo restart rsyslog

Changes to the configuration file won't work without that.

Revision history for this message
tallien (tallien) wrote :

Thanks Pavel. I restarted rsyslog. /var/log/debug is still empty but there were some additions to syslog so I have extracted those into a text file - attached.

Sorry, I know you specified to only try it once but I clicked a few times due to the lack of response from the applet submenu (I was not sure whether it was picking up on my clicks or not). So the log is a bit long. You can probably skip to the last time segment and ignore the earlier attempts, I guess they are all repeats of the same thing. I was not sure what to leave out so I left it all in :) If you need more info let me know.

Revision history for this message
Pavel Boldin (pboldin) wrote :

That is strange, but there are no traces of your attempt to activate in VPN, at least I don't see any.

OK. I hope that someone with more experience in network-manager will find this information useful.

If you want us to continue we can do so but in a private manner so we don't flood the ticket.

Revision history for this message
tallien (tallien) wrote :

Yes, that's what I meant when I said the VPN link in the applet submenu does not seem to react to my clicks. I click and nothing happens at all. But command line works fine so it seems like it must be an applet problem. If I had more knowledge I would look at the code that handles the menu interface but I don't know what to look for :)

I am happy to continue troubleshooting if you have the time. I agree I do not want to monopolize this ticket since it seems as though my issue is not quite the same as everyone else's. I will send an email to the address on your account. Thanks for your help!

Revision history for this message
Hugo Otto (hugootto) wrote :

I have the same situation as #77.
I did a fresh install (14.10), applied the newest updates, defined the VPN connection - and the error is there. Clicking the VPN entry in the applet does exactly nothing, logout/login solves the problem, connection is established

Revision history for this message
Trafex (trafex) wrote :

@Pavel Boldin; I've the debug log attached.
I first tried to capture the output of the nm-applet as described, but then it didn't showed me my VPN configuration.
So I added the debug config to the network manager and rsyslog.

This is the result when I tried to connect to 'vpn.myhost.com', hope it can help to find the cause.

Revision history for this message
Pavel Boldin (pboldin) wrote :

You seem to have exactly the same problem as I had.

Please, try to run nm-applet with a debug enabled (if VPN is not appearing at first run -- try to run it twice or so).

Anyway, it is not necessary for you to connect to VPN --- just show the debug output of nm-applet.

Revision history for this message
kehugter (kehugter) wrote :

Related?

Linux Mint 17 Cinnamon (Ubuntu 14.04), fresh install, openvpn 2.3.2

I had the same error messages. First as a dialogue complaining about the secrets. Then the dialogue didn't show any longer but the logs contained

> get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
> VPN service 'vpnc' disappeared

The issue was solved installing the package network-manager-openvpn-gnome

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

The only work-around that works for me is logging out and logging back in. Yet, as others have mentioned, this has to be done every time I boot my machine.

Since rebooting doesn't work, what does logout accomplish that reboot doesn't? That's an essential question. Perhaps Pavel has answered this in #60?

I'm on the verge of just reinstalling Ubuntu 14.10. This bug is the only failure of upgrading from 14.04 to 14.10 that I've experienced. Since I can't get it to go away in a permanent way, I've very close to doing a reinstall.

Revision history for this message
Pavel Boldin (pboldin) wrote :

I would like any of you guys to cooperate with my tightly to find the root cause for that.

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

Since my home folder is on another partition, I tried reinstalling 14.10 today over my "upgrade from 14.04 to 14.10" .

This did NOT fix the problem.

For me, the issue is exclusively with network-manager-vpnc connections. network-manager-openvpn connections have never exhibited this bug-behavior for me.

I still have to logout, after each boot of my machine, in order for VPNC to work through network-manager.

None of the fixes mentioned here have worked for me. I'm about to downgrade to 14.04. Ubuntu doesn't seem to care very much about 14.10 bugs. This bug has plenty of heat, but it persists on without rescue.

Revision history for this message
tallien (tallien) wrote :

Lonnie, it happened to me when I upgraded from 13.10 to 14.04, so I would be quite interested to see whether downgrading helps you.

I thought it was something that happened when I went to 14.04, but if you were ok when you were on 14.04, then maybe it is more to do with a change that was put into the vpnc code around that time period, and nothing to do with the OS versions...?

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

Well, I downgraded to 14.04 and the problem has gone away completely for me.

Nothing I tried with 14.10 worked. It may have worked if I had done a completely clean install (one where no existing /home partition existed). As I've mentioned, the problem began after I upgraded from 14.04 to 14.10. Then I installed 14.10 again, but I did this 14.10 install while having an existing /home partition (so not a completely clean reinstall).

There are two bugs why I cannot continue to run 14.10. This one, and one with Autokey-GTK:
https://bugs.launchpad.net/ubuntu/+source/autokey/+bug/1395415

Here are my thoughts on this bug. You'd think it have to do with one of those hidden configuration file in the /home/user directory. However, this may not be the case: people having tried deleting those config files and folder completely (so that they are recreated from scratch next use) and the problem didn't go away.

Have vpnc or network-manager packages changed since 14.04?

You can determine your version by typing this as a single line into the terminal:

sudo apt-get install apt-show-versions ; sudo apt-show-versions network-manager network-manager-vpnc

In 14.04, I get this output:

network-manager:amd64/trusty 0.9.8.8-0ubuntu7 uptodate
network-manager-vpnc:amd64/trusty 0.9.8.6-1ubuntu2 uptodate

What version of these are running in 14.10?

Revision history for this message
Jose Hernandez (jhjm32087) wrote :

Reply to #86, I'm getting these versions

network-manager:amd64/utopic 0.9.8.8-0ubuntu28 uptodate
network-manager-vpnc:amd64/utopic 0.9.8.6-2ubuntu1 uptodate

Revision history for this message
psylem (subnetjet) wrote :

I have this same issue on 14.10, it doesn't only impact VPN connections. Just try creating a WiFi connection with "All users may connect to this network" unchecked. In that case NetworkManager will attempt to access the Gnome Keyring security agent and fail for some unknown reason. This is where the problem lies.

In my case there is no need to delete that %gconf.xml file. Logging out and then in again allows NetworkManager to talk to my Login keyring correctly and everything just works again.

Not using Unity also works, or rather using Gnome (any of the Gnome desktop options after installing the gnome package).

Look at the last post on this thread, this provided me with the best clues as to where to look for what is going on here... http://forum.xfce.org/viewtopic.php?id=7458

Suggests there may be an issue with consolekit, what ever that may be. But that could be a red herring. The Debian bug report listed goes into more details about possible workarounds, none of which seemed applicable as the consolekit startx configuration required to work around that issue seems to already be in place in 14.10.

All I can say for certain is that NetworkManager can't talk to my Login keyring (even though there is nothing in there). Any ideas on how to decouple the Gnome Keyring dependancy entirely? I don't store passwords in the thing anyway.

Revision history for this message
tallien (tallien) wrote :

I have:

network-manager:i386/trusty 0.9.8.8-0ubuntu7 uptodate
network-manager-vpnc:i386/trusty 0.9.8.6-1ubuntu2 uptodate

on my 32-bit 14.04 install (upgraded from 13.10).

My clean 64-bit 14.04 install had the same problem right from the beginning, but it's possible I may have copied over my settings from my existing upgraded installation. Can't remember if I did that or not, but if I did then maybe that's what messed up my clean install.

Revision history for this message
Jonas Obrist (ojiidotch) wrote :

I have the same issue after upgrading from 14.04 to 14.10. Deleting ~/.gconf and logging in and out again solves the issue temporarily, but after a restart I have to delete it again, and log in and out again.

Revision history for this message
Julien Béti (julien-beti) wrote :

Following comment #72, I'm attaching the logs I got

Revision history for this message
monkeybrain2012 (kammon101) wrote :

I am also having this problem with fresh install of Ubuntu 14.04 and network-manager-openvpn

It works if I wait til wifi is connected before logging in. If login too soon then clicking the network-manger-applet tab has no effect. In that case the only way is to log out then login again.

Revision history for this message
mhogerheijde (o-launchpad-hogerheijde-net) wrote :
Download full text (3.5 KiB)

I'm having the same issue (for a while now, but I don't need VPN that much...)

Started since upgrade from 13.10 to 14.04, and still present in 14.10.

#34 Works for me (Deleting .gconf/apps/nm-applet/%gconf.xml)
#16 Doesn't work for me (Deleting keyring)

Log before removing .gconf/apps/nm-applet/%gconf.xml

--------------------------------------------
Jan 5 11:14:23 obelix NetworkManager[7538]: <info> Starting VPN service 'pptp'...
Jan 5 11:14:23 obelix NetworkManager[7538]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 8192
Jan 5 11:14:23 obelix NetworkManager[7538]: <info> VPN service 'pptp' appeared; activating connections
Jan 5 11:14:23 obelix NetworkManager[7538]: <error> [1420452863.97058] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Jan 5 11:14:23 obelix NetworkManager[7538]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
Jan 5 11:14:27 obelix NetworkManager[7538]: <info> VPN service 'pptp' disappeared
--------------------------------------------

Logs after removing

--------------------------------------------
Jan 5 11:18:42 obelix NetworkManager[7538]: <info> Starting VPN service 'pptp'...
Jan 5 11:18:42 obelix NetworkManager[7538]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 10023
Jan 5 11:18:42 obelix NetworkManager[7538]: <info> VPN service 'pptp' appeared; activating connections
Jan 5 11:18:43 obelix NetworkManager[7538]: <info> VPN plugin state changed: starting (3)
Jan 5 11:18:43 obelix NetworkManager[7538]: <info> VPN connection 'VPN Connection 1' (Connect) reply received.
--------------------------------------------

$ dpkg -l | grep network-manager
ii network-manager 0.9.8.8-0ubuntu28
ii network-manager-gnome 0.9.8.8-0ubuntu7
ii network-manager-openvpn 0.9.8.4-2ubuntu1
ii network-manager-openvpn-gnome 0.9.8.4-2ubuntu1
ii network-manager-pptp 0.9.8.2-1ubuntu2
ii network-manager-pptp-gnome 0.9.8.2-1ubuntu2

$ lsb_release -a
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia...

Read more...

Revision history for this message
Dragomir Deltchev (drago-g) wrote :

Dears,

what was the problem in my case. After connecting to VPN using openvpn, I was not able to browse the internet. The solution:
 1) in the advanced section to set the Getaway port to 443
 2) to check use TCP connection
 3) Save

I hope it works for you

Greetings
Drago

Revision history for this message
Trent Lloyd (lathiat) wrote :

Fresh 14.10 install, literally on first boot, note that I installed from the alternate installer.

This hit me, at first I couldn't connect to wireless (didn't ask for the password). Manually configuring it in the config to already have the password set let that work. Same errors in syslog, about the agent not being available.

Then I installed the openconnect plugin and it wouldn't prompt for the password.

Removing the nm-applet prefs and relogging fixed the issue: ~/.gconf/apps/nm-applet/%gconf.xml

Revision history for this message
Weitian Leung (timxx) wrote :

Please please do fix this asap, though delete ~/.gconf resolve the problem , but not for a restart.

Revision history for this message
Weitian Leung (timxx) wrote :

Hi, everybody, finally I found a solution for fixing this:

http://askubuntu.com/questions/57339/connect-disconnect-from-vpn-from-the-command-line

Just do as the above link answer said, it works for me (even after restarting)

Revision history for this message
Lee H (leehodg) wrote :

Hi, I get this bug also (14.04):

    Feb 9 09:13:48 titania NetworkManager[799]: <info> Starting VPN service 'pptp'...
    Feb 9 09:13:48 titania NetworkManager[799]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 5573
    Feb 9 09:13:48 titania NetworkManager[799]: <info> VPN service 'pptp' appeared; activating connections
    Feb 9 09:13:48 titania NetworkManager[799]: <error> [1423448028.441626] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
    Feb 9 09:13:48 titania NetworkManager[799]: <info> Policy set 'leewifi' (wlan0) as default for IPv4 routing and DNS.
    Feb 9 09:13:53 titania NetworkManager[799]: <info> VPN service 'pptp' disappeared

login/logout after booting works for a temp fix, but this is the only thing that has worked. Deleting gconf or secrets did nothing.
If I trying with "nmcli con up id ConnectionName" I get an error about no secrets.

Finally if I try the fix posted directly above by Weitian (i.e. editing /etc/NetworkManager/system-connections/ConnectionName to store vpn secrets directly and setting password-flags=0), my vpn looks like it attempts a connection as the wifi signal symbol alternates a padlock overlayed, but finally it gives up and gives the helpful msg (if using nmcli)

    Error: Connection activation failed: unknown reason.

Revision history for this message
Helmo (helmo) wrote :

thanks @timxx

Revision history for this message
Matthew D. Mower (mdmower) wrote :

Like #96, I also am experiencing this issue with a clean install of Ubuntu 14.10 (64bit). I originally had this problem upon upgrading from 14.04 to 14.10. I decided it would be a good opportunity to start fresh, so I chose the "erase disk" option during install (just trying to stress this really is a clean install of regular, unmodified Ubuntu).

Feb 18 02:59:21 4770K NetworkManager[924]: <info> Starting VPN service 'openvpn'...
Feb 18 02:59:21 4770K NetworkManager[924]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 2854
Feb 18 02:59:21 4770K NetworkManager[924]: <info> VPN service 'openvpn' appeared; activating connections
Feb 18 02:59:21 4770K NetworkManager[924]: <error> [1424249961.215149] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Feb 18 02:59:21 4770K NetworkManager[924]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
Feb 18 02:59:25 4770K NetworkManager[924]: <info> VPN service 'openvpn' disappeared

information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Sebastian Podjasek (sebastian-podjasek) wrote :

From about a week back I get this annoying situation every time. After start-up, no VPN connection secrets are visible to nm, need to remove .gconf file, logout, login. Killing nm-applet after removing file does not fix it, logout-login required.

Revision history for this message
John Kuang (xiphosurus) wrote :

Seeing the same "Failed to request VPN secrets" problem in 14.10, and can confirm that a workaround is simply to log out and log back in, WITHOUT rebooting.

#34 works simply because of the logging in and out, not because of moving/deleting the .gconf directory or its contents.

#98's workaround is not acceptable as it stores the VPN password in plaintext.

Revision history for this message
Marc Iulian (vibelinux) wrote :

Any update on this ? It's very frustrating to be needed to logout every single time I want to connect to the VPN. I can't believe how indifferent are the devs about fixing such a basic, needed functionality of an operating system. Because of simple things like this that don't work as expected people that are willing to switch to Linux simply quit trying. It's very frustrating.

Revision history for this message
Pavel Boldin (pboldin) wrote :

Well, I provided the patch that works for me (I have built an updated package for myself).

I can provide a PPA for you to check if it fixes your problem.

Revision history for this message
Jonas Obrist (ojiidotch) wrote :

A PPA with a possible fix would be greatly appreciated.

Revision history for this message
Pavel Boldin (pboldin) wrote :

So I managed to provide an PPA with network-manager-applet built with my fix presented above.

You can use updated package by running:

$ sudo add-apt-repository ppa:pboldin/nm
$ sudo apt-get update
$ sudo apt-get dist-upgrade -y

It should install version 0.9.8.8-0ubuntu4.4~fixed:
$ dpkg-query -s network-manager-gnome
...
Source: network-manager-applet
Version: 0.9.8.8-0ubuntu4.4~fixed
...

Revision history for this message
Marc Iulian (vibelinux) wrote :

Can you fix the PPA please ?

W: Failed to fetch http://ppa.launchpad.net/pboldin/nm/ubuntu/dists/utopic/main/binary-amd64/Packages 404 Not Found
W: Failed to fetch http://ppa.launchpad.net/pboldin/nm/ubuntu/dists/utopic/main/binary-i386/Packages 404 Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.10
DISTRIB_CODENAME=utopic
DISTRIB_DESCRIPTION="Ubuntu 14.10"
NAME="Ubuntu"
VERSION="14.10 (Utopic Unicorn)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.10"
VERSION_ID="14.10"

Revision history for this message
Pavel Boldin (pboldin) wrote :

Marc, I have uploaded a version for the Ubuntu Utopic.

Please try again.

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

pavel can you please provide a debdiff against trusty and utopic? this way we might ask for an SRU

Revision history for this message
Marc Iulian (vibelinux) wrote :

Thanks Pavel. Everything seems to work ok so far, thank you.

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :
summary: - Virtual private network connection fails after distribution upgrade due
- to outdated Network Manager configuration files
+ [SRU] Virtual private network connection fails after distribution
+ upgrade due to outdated Network Manager configuration files
description: updated
Revision history for this message
ariel cornejo (arielco) wrote :

I applied the patch from source, and it's working now (thanks Pavel).

My only remark is that I'm running psensor as a startup application, and the nm-applet won't show the VPN connections in the menu until the psensor window has come up. Weird.

Revision history for this message
Pavel Boldin (pboldin) wrote :

LocutusOfBorg (or should I call you Captain Picard? ;-),

Will this patch be enough for you or is there some more actions I should take on?

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

Hi Pavel :)
This should be enough for developers and sponsor to look at it. Unfortunately I can't upload because I'm not an Ubuntu Developer

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Wouldn't this also apply to Vivid? I look at find that the upstream code should be about the same:
https://git.gnome.org/browse/network-manager-applet/tree/src/shell-watcher.c?h=nma-0-9-10#n154

To ship a fix like this as SRU, it would first need to land in the current development release assuming it's still a problem there. I can't reproduce the issue here; using Unity. I can successfully reconnect to my VPN regardless of whether the previous connection was disconnected normally or failed.

description: updated
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

I've updated the description, but I'm not convinced it has anything to do with upgrading a system; given how the patch included here has been noticed to work.

However, since it's not upstream, could someone having the issue also report the bug on the upstream bug tracker (at GNOME)?
You can follow the steps at http://wiki.ubuntu.com/Bugs/Upstream/GNOME.

Revision history for this message
Clemens Lang (neverpanic) wrote :

I think this no longer applies upstream, because https://bugzilla.gnome.org/show_bug.cgi?id=707953 and the fix for it completely removed src/shell-watcher.c, where the patch was necessary.

Because of that, I would recommend to apply the patch to the current version as it is in Ubuntu.

I can also confirm that the patch solves the problem on my utopic system.

Revision history for this message
Martins Jakubovics (martins-k) wrote :

Hello all,

Ubuntu 15.04 x64, just happened to me.
Have same error: get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Workaround in #34 helped for me.

Revision history for this message
c2h5oh (c2h5oh) wrote :

Same problem with 15.04 x64 since upgrade from 14.10

I've tested all the workarounds mentioned in this thread and sadly no dice.

If I edit the connection configuration files in /etc/NetworkManager/system-connections and change password-flags to 0 + add:
[vpn-secrets]
password=my_password

and restart I am able to connect every single time, but the connection doesn't work (can't reach any hosts)

Revision history for this message
Marc Iulian (vibelinux) wrote :

Had the same problem on 15.04. I manually add the route but in 15.04 NM seems to be changed and no longer works. What I did instead is to add the manual route normally but changed the gateway (routes -> gateway) to 0.0.0.0 , that worked for me. I hope it can help you too. Additionally, you can try change the route to something like: sudo ip r a 10.0.0.0/8 dev ppp0 - this also worked for me.

Revision history for this message
Trent Lloyd (lathiat) wrote :

I keep running into this on multiple installations, with openconnect.

Removing only ~/.gconf/apps/nm-applet/%gconf.xml always fixes it for me, yet that file is basically blank with just a change time.
And it gets recreated yet continues to work (for quite some time) but occasionally I have to remove it again.

Just logging out/in doesn't fix it, can be broken for days or weeks. Obviously removing that file triggers something to occur as that file itself does not change contents.

Revision history for this message
D (360-dennis) wrote :

I'm on 15.04, coming from 14.10 and none of the workarounds work for me. I just start the openvpn connection through the cli.

Revision history for this message
clickwir (clickwir) wrote :

I'm also on 15.04 after upgrading from 14.10. OpenVPN.

Only tried once so far, but it worked. I removed ~/.gconf/apps/nm-apples/%gconf.xml and logged out and logged in with the same account. VPN connected fine.

Revision history for this message
Robert Grønning (slimg) wrote :

I just got the problem as described with my OpenVPN today on my Ubuntu 15.04 installation, I have not upgraded, I've installed it from scratch.

OpenVPN has worked well now for a month since the reinstall, but today I got the problem, and now have to delete ~/.gconf/apps/nm-applet/%gconf.xml and log in again to make the OpenVPN connection work trough nm-applet.

Revision history for this message
badrobot (michael-felder) wrote :

I'm seeing this issue on 15.04. I upgraded from 14.04 though over 2 month ago and the configuration was working fine. I just ran and update and reboot the system and noticed that vpn and spotify are not working

Jun 9 16:52:12 masterkey NetworkManager[1141]: <error> [1433883132.058925] [vpn-manager/nm-vpn-connection.c:1778] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

I submitted a bug similar to this a couple of weeks ago for Ubuntu 15.04:
https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1459350

Is this the same thing or different?

Revision history for this message
Pavel Boldin (pboldin) wrote :

@Lonnie,

Just run a `nm-applet' and see if there is messages that the `Shell version is unable to be found.' or alike.

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

nm-applet :

(nm-applet:4385): nm-applet-WARNING **: Could not find ShellVersion property on org.gnome.Shell after 5 tries

tags: added: vivid
Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

From April 2015 until around May 27th 2015, I did not experience this bug in Ubuntu 15.04.

Then all of a sudden it returned. I couldn't find this bug from before (see comment #86 above). So I submitted this bug for vivid:
https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1459350

As you can see in comment 86, I've already been through this once. I was unable to enjoy Ubuntu 14.10, because I had to downgrade back to Ubuntu 14.04 due to this bug.

In Ubuntu 15.04, for two months I've enjoyed it, but because of this bug a may have to downgrade to 14.04 again!

Revision history for this message
Benjamin Xiao (ben-r-xiao) wrote :

I have the same problem as Lonnie. A recent update or something caused this. It was working fine for a while.

I should note that my laptop running Ubuntu 15.04 doesn't have this issue, but my desktop does.

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

I just reinstalled Ubuntu 15.04 (hand selecting only a hand full of hidden configuration files to place into my home directory so that I would not have to reconfigure these certain applications).

I can't believe it. This bug is still there. Back to Ubuntu 14.04 I go. This is the second upgrade (14.10 and now 15.04) that I cannot enjoy due to this bug! So frustrating! Back to 14.04 once more :(

Revision history for this message
Benjamin Xiao (ben-r-xiao) wrote :

Lonnie, did you install updates before you tried it?

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

@Benjamin Xiao : No, I didn't think to try that. It would have probably worked before the updates (like it did for the first 2 months of 15.04).

Right now I'm typing to you from a freshly installed 14.04 where vpnc is working just fine. I've never gotten this to work in 14.10, and (like you know) it worked in 15.04 for about 2 months and then stopped working again.

Back in the day (I've been using Ubuntu since version 7.04), this crap would have gotten fixed by now. These days I think the core developers are focused on telephones and Unity 8 :)

Oh well . . .

Revision history for this message
Benjamin Xiao (ben-r-xiao) wrote :

I don't have to remove the gconf file. I just logout and log back in and things seem to work again.

Is anyone working on this? It's been over a year!

I can provide any necessary logs.

Revision history for this message
Pavel Boldin (pboldin) wrote :

If I'm right the fix I've already provided in PPA for the Utopic and Trusty should work for Vivid as well. The problem is I have not really compiled it for Vivid yet.

Revision history for this message
Benjamin Xiao (ben-r-xiao) wrote :

@Pavel, why does the shell notify event happen for some machines but not others?

tags: added: wily
Revision history for this message
Pavel Boldin (pboldin) wrote :

This is a mistery we yet have to solve.

But the assumption on the availability of Shell for the proper operation of nm-applet is not a right thing to do.

Revision history for this message
Benjamin Xiao (ben-r-xiao) wrote :

Well I have two machines, one that consistently doesn't work on first login and another one that always works. I can provide debug logs and anything else necessary if you need them.

Revision history for this message
Pavel Boldin (pboldin) wrote :

@Benjamin, I could gather all the logs at my computer if I wanted so -- I had exact the same problem.

Yet, I do think that the fix provided by me is a correct one and there is no necessity in debugging the problem further.

Revision history for this message
Benjamin Xiao (ben-r-xiao) wrote :

Anyway we can expedite that fix into the main repos then?

Revision history for this message
Benjamin Xiao (ben-r-xiao) wrote :

Interestingly enough, on the computer that works, if I kill nm-applet and restart it manually in CLI, I see the shell version warning message and VPN doesn't work. Is Unity launching it differently somehow?

RIght now, I'll settle for a way to workaround it without having to logout.

Revision history for this message
Pavel Boldin (pboldin) wrote :

I have uploaded a fixed package for Ubuntu Vivid to the my PPA as well:
https://launchpad.net/~pboldin/+archive/ubuntu/nm

Take a look at the https://bugs.launchpad.net/ubuntu/+source/network-manager-vpnc/+bug/1297849/comments/107 for instructions.

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

Who would have to approve your fix, so that it comes as an official update on these version of Ubuntu that have this bug?

Pavel, it seems you've done the hard work. Who now must come alone an approve and distribute this via an official update?

Revision history for this message
Marc Iulian (vibelinux) wrote :

We all appreciate your work Pavel. One question tho: I've added your PPA and ran the upgrade, now I see:

Source: network-manager-applet
Version: 0.9.10.1-0ubuntu5~fixed

In your comment the version is 0.9.8.8-0ubuntu4.4~fixed . What is different in 0.9.10.1-0ubuntu5~fixed ? Since is not working (only works if I logout then login again).

Revision history for this message
Andy Hawkins (a904guy) wrote :

Confirmed fix from upgrade is .gconf > .gconf-backup.

Revision history for this message
Pavel Boldin (pboldin) wrote :

@Marc, the version in the comment with instructions is for the Trusty and Utopic. The 0.9.10.1-0ubuntu5~fixed is for Vivid.

Can you please show me the output of the following command:
 dpkg-query -q network-manager-applet

Revision history for this message
Martins Jakubovics (martins-k) wrote :

Hi,
Pavel's patch (0.9.10.1-0ubuntu5~fixed for Vivid) works for me.
Thanks!

Revision history for this message
D (360-dennis) wrote :

It worked for me too, i have installed;
Version: 0.9.10.1-0ubuntu5~fixed
I had to reboot for it to work.

I used to be on 14.10 and upgraded to 15.04. Pavel, Thanks for all the work!!

Revision history for this message
Roman Lenskij (romanlenskij) wrote :

Ubuntu 15.04 (vivid) still affected.

Revision history for this message
Pavel Boldin (pboldin) wrote :

@Roman, have you tried to reboot?

Pavel Boldin (pboldin)
description: updated
Revision history for this message
Roberto Leinardi (leinardi) wrote :

Deleting .gconf/apps/nm-applet/%gconf.xml solved for me.

Thanks

Revision history for this message
Steve Walker (swalker2001) wrote :
Download full text (5.2 KiB)

This didn't work for me :-(

$ dpkg-query -s network-manager-gnome

Package: network-manager-gnome
Status: install ok installed
Priority: optional
Section: gnome
Installed-Size: 6921
Maintainer: Ubuntu Developers <email address hidden>
Architecture: amd64
Source: network-manager-applet
Version: 0.9.10.1-0ubuntu5~fixed

...

When I try to establish a connection I get the following. Wondering if I am experiencing this bug or something different:

Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> Starting VPN service 'pptp'...
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 6789
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> VPN service 'pptp' appeared; activating connections
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> VPN connection 'Dallas' (ConnectInteractive) reply received.
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> VPN plugin state changed: starting (3)
Jun 21 16:27:16 steve-dell NetworkManager[756]: ** Message: pppd started with pid 6793
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> VPN connection 'Dallas' (Connect) reply received.
Jun 21 16:27:16 steve-dell pppd[6793]: Plugin /usr/lib/pppd/2.4.6/nm-pptp-pppd-plugin.so loaded.
Jun 21 16:27:16 steve-dell NetworkManager[756]: Plugin /usr/lib/pppd/2.4.6/nm-pptp-pppd-plugin.so loaded.
Jun 21 16:27:16 steve-dell NetworkManager[756]: ** Message: nm-pptp-ppp-plugin: (plugin_init): initializing
Jun 21 16:27:16 steve-dell pppd[6793]: pppd 2.4.6 started by root, uid 0
Jun 21 16:27:16 steve-dell NetworkManager[756]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 3 / phase 'serial connection'
Jun 21 16:27:16 steve-dell pppd[6793]: Using interface ppp0
Jun 21 16:27:16 steve-dell pppd[6793]: Connect: ppp0 <--> /dev/pts/0
Jun 21 16:27:16 steve-dell NetworkManager[756]: Using interface ppp0
Jun 21 16:27:16 steve-dell NetworkManager[756]: Connect: ppp0 <--> /dev/pts/0
Jun 21 16:27:16 steve-dell NetworkManager[756]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 5 / phase 'establish'
Jun 21 16:27:16 steve-dell pptp[6797]: nm-pptp-service-6789 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Jun 21 16:27:16 steve-dell systemd[1]: Started ifup for ppp0.
Jun 21 16:27:16 steve-dell systemd[1]: Starting ifup for ppp0...
Jun 21 16:27:16 steve-dell NetworkManager[756]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> (ppp0): new Generic device (driver: 'unknown' ifindex: 10)
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> (ppp0): exported as /org/freedesktop/NetworkManager/Devices/9
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
Jun 21 16:27:16 steve-dell NetworkManager[756]: <info> device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
Jun 21 16:27:16 steve-dell sh[6802]: Unknown interface ppp0
Jun 21 16:27:47 steve-dell pppd[6793]: LCP: timeout sending Config-Requests
Jun 21 16:27:47 steve-dell pppd[6793]: Connection terminated.
Jun 21 16:27:47 ...

Read more...

Revision history for this message
Stefan Taferner (taferner) wrote :

Pavel's patch (0.9.10.1-0ubuntu5~fixed for Vivid) also fixes the problem for me.
Had to reboot to make it work (probably restarting the network manager would have been sufficient)

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

If you need to do anything more than 'killall nm-applet' and starting nm-applet again, then it's quite unlikely that this patch really fixes the issue -- I did notice this issue *once* on my system yesterday and logged off and back in, from there the agent could be detected. This doesn't seem to me like either shell version detection or something related to upgrading (given I wasn't doing an upgrade at all).

Since then, I've tried to kill off my VPN or terminate it normally, neither method works to reproduce the problem: I can immediately start it again, and I do get the authentication dialog and I am able to reconnect normally.

Anyone can add further information on this bug, or can verify that without the patch, stopping nm-applet and restarting it will make things work again, or can make things work without needing to reboot (only restarting nm-applet, with the patch applied)?

There's still a branch for 0.9.10, 0.9.8, etc. It would be best if someone was to report the bug upstream or otherwise contact upstream developers to get a review of the patch.

tags: added: sts
Revision history for this message
Pavel Boldin (pboldin) wrote :

@Mathieu,

The patch is not appropriate for the upstream because the upstream has this code removed.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Still, it's nice to get it reviewed anyway. Like I said, there are still code branches for the previously-released versions of nm-applet, and fixing it could benefit other distros.

Changed in network-manager-applet (Ubuntu):
status: New → In Progress
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager-applet - 0.9.10.1-0ubuntu6

---------------
network-manager-applet (0.9.10.1-0ubuntu6) wily; urgency=medium

  * Fix VPNs unable to connect before re-login. (LP: #1297849)

 -- Pavel Boldin (davinchi) <email address hidden> Wed, 22 Jul 2015 11:17:38 -0400

Changed in network-manager-applet (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

I see that the status is "Fix Released". Does this mean if I upgraded from 14.04 to 15.04 (right now), I would not experience this bug anymore?

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

Nope, it means it is fixed in the development release, aka wily or 15.10.
An SRU should followup for a fix in the currently supported releases.

Fixing in the dev release is the first step.

cheers,

G.

Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Prem, or anyone else affected,

Accepted network-manager-applet into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/network-manager-applet/0.9.8.8-0ubuntu4.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in network-manager-applet (Ubuntu Trusty):
status: New → Fix Committed
tags: added: verification-needed
Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

14.04 is Trusty, right? Well, 14.04 doesn't exhibit this bug. 14.10 does, and after upgrading to 14.10 I had to go back to 14.04 because of this bug. 15.04 did not exhibit this bug either (until a couple of months after release), then there too I had to downgrade to 14.04 again to avoid this bug.

Perhaps this fix won't hurt (the working fine) 14.04, but I thought I should at least restate my experience with this bug, in light of the previous message, that emphasizes Trusty, which (for me) I don't ever recall ever having this bug in 14.04. I'm using 14.04 right now, and do not experience this bug.

Revision history for this message
Audun Gangsto (audun-m) wrote :

Me and the users in my company are still seeing this bug on 14.04

We really appreciate the effort to fix this, and we will start testing the proposed package and let you know about the results.

Revision history for this message
Pavel Boldin (pboldin) wrote :

Can you please provide the logs?

Revision history for this message
D (360-dennis) wrote :

i too see this bug, even after installing the private fix from pavel's ppa. I _think_ (i'm not sure) i see this bug on new wifi connections (where i haven't connected before). do you need logs from my system too? I'm on 15.04

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

I can also confirm that Pavel's patch works. Here are the steps I did:

Patch for Ubuntu 15.04 (vivid):

1) Open the sources file using the nano file editor:
sudo nano /etc/apt/sources.list

2) Add these two lines to the bottom of the /etc/apt/sources.list file:

deb http://ppa.launchpad.net/pboldin/nm/ubuntu vivid main
deb-src http://ppa.launchpad.net/pboldin/nm/ubuntu vivid main

3) Hold down ctrl and press o and then press enter. Now hold down ctrl+x, to exit nano.

4) Enter these command:
sudo apt-get update ; sudo apt-get upgrade

5) Reboot your computer.

Why is this patch having such a hard time making it into the main repositories?

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-openconnect (Ubuntu Trusty):
status: New → Confirmed
Changed in network-manager-openvpn (Ubuntu Trusty):
status: New → Confirmed
Changed in network-manager-vpnc (Ubuntu Trusty):
status: New → Confirmed
Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

@pboldin

I've been running your patch repository in Ubuntu 15.04, and my "saved" credentials keep getting forgotten for vpnc connections:

https://bugs.launchpad.net/bugs/1465348

Is it possible that this could be caused by your patch?

Revision history for this message
Pavel Boldin (pboldin) wrote :

It could be but I will require logs from all the services to be sure.

I think I need to create a log-gathering script.

Mathew Hodson (mhodson)
affects: hundredpapercuts → network-manager-applet
Changed in network-manager-applet:
status: Triaged → Invalid
Changed in network-manager-applet (Ubuntu Trusty):
importance: Undecided → Medium
Revision history for this message
Kostadin Stoilov (kmstoilov) wrote :

Affected by this bug on up to date Ubuntu 14.04.

Workaround in #40 solves the issue.

Syslog:

Oct 4 16:39:13 kostadin-Ubuntu NetworkManager[1032]: <info> Starting VPN service 'openvpn'...
Oct 4 16:39:13 kostadin-Ubuntu NetworkManager[1032]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 8637
Oct 4 16:39:13 kostadin-Ubuntu NetworkManager[1032]: <info> VPN service 'openvpn' appeared; activating connections
Oct 4 16:39:13 kostadin-Ubuntu NetworkManager[1032]: <error> [1443965953.992100] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Oct 4 16:39:18 kostadin-Ubuntu NetworkManager[1032]: <info> VPN service 'openvpn' disappeared

Revision history for this message
Evan Broder (broder) wrote :

@brian-murray: I just installed the package from proposed on trusty and it seems to have improved things, although there's a 5-10 second delay after nm-applet starts up where it hasn't registered itself as a secrets provider. Still, this seems to be an improvement in behavior.

tags: added: verification-done-trusty
Mathew Hodson (mhodson)
affects: network-manager-applet → hundredpapercuts
Changed in hundredpapercuts:
status: Invalid → Confirmed
tags: removed: verification-needed
Changed in network-manager-openconnect (Ubuntu Trusty):
importance: Undecided → High
Changed in network-manager-openvpn (Ubuntu Trusty):
importance: Undecided → High
Changed in network-manager-vpnc (Ubuntu Trusty):
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager-applet - 0.9.8.8-0ubuntu4.4

---------------
network-manager-applet (0.9.8.8-0ubuntu4.4) trusty; urgency=medium

  * Fix VPNs unable to connect before re-login. (LP: #1297849)

 -- Pavel Boldin (davinchi) <email address hidden> Wed, 22 Jul 2015 11:17:38 -0400

Changed in network-manager-applet (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Chris J Arges (arges) wrote : Update Released

The verification of the Stable Release Update for network-manager-applet has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Lonnie Lee Best (launchpad-startport) wrote :

Is this bug fixed in Ubuntu 15.10? I'm considering upgrading from 14.04 to 15.10, but I don't want to do it if doing so will require me to address this bug again.

Revision history for this message
D (360-dennis) wrote :

I'm sorry to report the bug still occurs in 15.10. I installed a fresh copy on my XPS13 and i had to click 13 times on VPN to start it on a unknown wifi network. If you need my logs, let me know. I still monitor this thread.

Revision history for this message
reliable-robin-22 (nicolasdiogo) wrote :

hi,

It has appeared after months using 15.10

I added a number of VPN connection and now all of them are failing ....

It also highlights the short-coming in importing multiple VPN connections and setting their username and password

thanks,

Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Hello Prem, or anyone else affected,

Accepted network-manager-openconnect into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/network-manager-openconnect/1.2.0-0ubuntu0.16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-needed
no longer affects: network-manager-applet (Ubuntu Xenial)
Changed in network-manager-openconnect (Ubuntu):
status: Triaged → Fix Released
Changed in network-manager-openconnect (Ubuntu Xenial):
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-openvpn (Ubuntu Xenial):
status: New → Confirmed
Changed in network-manager-vpnc (Ubuntu Xenial):
status: New → Confirmed
Revision history for this message
Jan Henke (jhe) wrote :

I have tested the proposed version 1.2.0-0ubuntu0.16.04.1 of network-manager-openconnect and it fixed the problems for me.

tags: added: verification-done-xenial
Revision history for this message
Aron Xu (happyaron) wrote :

Works for me, marking as verification-done.

tags: added: verification-done
removed: verification-needed
Revision history for this message
D (360-dennis) wrote :

I'm sorry, i read https://wiki.ubuntu.com/Testing/EnableProposed but i can't figure out how to install the proposed package. I tried
- Create the file /etc/apt/preferences.d/proposed-updates with this content:
Package: *
Pin: release a=xenial-proposed
Pin-Priority: 400
sudo apt-get upgrade -s
i got "network-manager-gnome (1.2.0-0ubuntu0.16.04.3 Ubuntu:16.04/xenial-updates [amd64])"
is that the correct package? It says
"network-manager-openconnect 1.2.0-0ubuntu0.16.04.1" on
https://launchpad.net/ubuntu/+source/network-manager-openconnect/1.2.0-0ubuntu0.16.04.1
- sudo aptitude -t xenial-proposed
does not work for me, but im on 16.04..
After installing aptitude, it gave me
"The Value 'xenial-proposed' is invalid for APT:: Default-Release as such a release is not available in the sources"

I'm thinking the page about Testing/EnabledProposed needs an update (checkbox-gtk does not work for me too for uploading the hardware profile). In the meantime, could some tell this newbielinux how to install the proposed package? And how to uninstall it after testing?

Revision history for this message
Mo (alim0x) wrote :

@6-dennis: Maybe you can try

System Settings - Software & Updates - Developer Options

There is an option of 'xenial-proposed'

Revision history for this message
khoonirobo@gmail.com (khoonirobo) wrote :

In Xenial

on testing

network-manager-openconnect
network-manager-openconnect-gnome

Works fine.

Mathew Hodson (mhodson)
Changed in network-manager-openconnect (Ubuntu Xenial):
importance: Undecided → High
Changed in network-manager-openvpn (Ubuntu Xenial):
importance: Undecided → High
Changed in network-manager-vpnc (Ubuntu Xenial):
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package network-manager-openconnect - 1.2.0-0ubuntu0.16.04.1

---------------
network-manager-openconnect (1.2.0-0ubuntu0.16.04.1) xenial; urgency=medium

  * SRU to 1.2.0 release to match NM version (LP: #1297849)

 -- Aron Xu <email address hidden> Fri, 27 May 2016 16:09:01 +0800

Changed in network-manager-openconnect (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
ubuntu user (aaadas) wrote :

Problem pops up again for me after upgrading from 15.10 to 16.04.
This time error message is a bit different:

<error> [1468865322.8065] vpn-connection[0x29d15b0,aaaa,"XXX",0]: Failed to request VPN secrets #3: No agents were available for this request.

Ubuntu 16.04
dpkg --list |grep openconnect
ii libopenconnect5:amd64 7.06-2build2 amd64 open client for Cisco AnyConnect VPN - shared library
ii network-manager-openconnect 1.2.0-0ubuntu0.16.04.1 amd64 network management framework (OpenConnect plugin)
ii network-manager-openconnect-gnome 1.2.0-0ubuntu0.16.04.1 amd64 network management framework (OpenConnect plugin GNOME GUI)
ii openconnect 7.06-2build2 amd64 open client for Cisco AnyConnect VPN

Connection from command line is working.
I tried to recreate connection and reinstalling. What else can I try?

Revision history for this message
Ramonskie (ramonskie) wrote :

same issue here stopped working since a few days ago
im on 16.04 as wel with

network-manager-openconnect:
  Installed: 1.2.0-0ubuntu0.16.04.1

Revision history for this message
Vasili Burdo (vburdo) wrote :
Download full text (25.4 KiB)

(repost from bug #1247682)

Hi, same problem after upgrade to Xenial.
Sometimes VPN connect succeeds, but most often it fails.
Using openconnect from command line always works.

Here are debug logs for both failed and successful and connection attempts:

-------------------------FAILED ATTEMPT:BEGIN------------------------
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5877] active-connection[0x293b400]: set device "eno1" [0x28db5f0]
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5877] device[0x28db5f0] (eno1): add_pending_action (1): 'activation::0x293b400'
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5877] active-connection[0x293b400]: constructed (NMVpnConnection, version-id 10)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5878] auth: call[435]: CheckAuthorization(org.freedesktop.NetworkManager.network-control), subject=unix-process[pid=12623, uid=1000, start=23699935]
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5885] auth: call[435]: CheckAuthorization succeeded: (is_authorized=1, is_challenge=0)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5889] active-connection[0x293b400]: set state activating (was unknown)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.5889] active-connection[0x293b400]: check-master-ready: not signalling (state activating, no master)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <info> [1469615162.5890] audit: op="connection-activate" uuid="ab76ecac-1eab-4b32-86c7-6524528c5f89" name="Testvpn.CISCO" pid=12623 uid=1000 result="success"
Jul 27 13:26:02 myubuntu NetworkManager[856]: <info> [1469615162.5969] vpn-connection[0x293b400,ab76ecac-1eab-4b32-86c7-6524528c5f89,"Testvpn.CISCO",0]: Started the VPN service, PID 2409
Jul 27 13:26:02 myubuntu NetworkManager[856]: <info> [1469615162.6027] vpn-connection[0x293b400,ab76ecac-1eab-4b32-86c7-6524528c5f89,"Testvpn.CISCO",0]: Saw the service appear; activating connection
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6028] vpn-connection[0x293b400,ab76ecac-1eab-4b32-86c7-6524528c5f89,"Testvpn.CISCO",0]: requesting VPN secrets pass #1
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6031] Secrets requested for connection /org/freedesktop/NetworkManager/Settings/2 (Testvpn.CISCO/vpn)
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6032] settings-connection[0x28ad9f0,ab76ecac-1eab-4b32-86c7-6524528c5f89]: (vpn:0x2a421b0) secrets requested flags 0x80000004 hints '(none)'
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6035] agent-manager: ([0x2a421b0/"Testvpn.CISCO"/"vpn"]) system settings secrets sufficient
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6038] settings-connection[0x28ad9f0,ab76ecac-1eab-4b32-86c7-6524528c5f89]: (vpn:0x28ec700) existing secrets returned
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6039] settings-connection[0x28ad9f0,ab76ecac-1eab-4b32-86c7-6524528c5f89]: (vpn:0x28ec700) secrets request completed
Jul 27 13:26:02 myubuntu NetworkManager[856]: <debug> [1469615162.6044] settings-connection[0x28ad9f0,ab...

Revision history for this message
Freak (rrtaft) wrote :

There seems to be another issue causing what was mentioned in the last 3 posts not related to this bug. Once the window is open to enter your credentials, if you don't fill them out quick enough, you can get the 'Failed to request VPN secrets #3: No agents were available for this request.'. This includes fresh installs of Xenial, we have four Mint 18 users that are experiencing this. It appears to work 'sometimes', then a few users discovered you just have to login really quick for it to work. This is with network-manager-openconnect 1.2.0-0ubuntu0.16.04.1

Revision history for this message
Vasili Burdo (vburdo) wrote :

Hm,

I tried to upgrade network-manager-openconnect and network-manager-openconnect-gnome to Yakkety version (i.e. 1.2.2-1) - downloaded .debs from https://launchpad.net/ubuntu/+source/network-manager-openconnect/

First impression, looks like it fixes the problem.
At least 3 connect attempts with varying delays in GUI go smooth.

And it looks like witchery, because .diff shows there was no code changes between Xenial and Yakkety - only metadata fixes.

Anyways, let's wait couple of days. Will keep this thread updated.

Revision history for this message
Ovidiu-Florin BOGDAN (ovidiu-florin) wrote :

I'm also experiencing this after an upgrade from Xenial to Yakety (Kubuntu)

Philip Muškovac (yofel)
no longer affects: network-manager-applet (Ubuntu Yakkety)
no longer affects: network-manager-openconnect (Ubuntu Yakkety)
Changed in network-manager-openvpn (Ubuntu Yakkety):
importance: Undecided → High
status: New → Confirmed
Changed in network-manager-vpnc (Ubuntu Yakkety):
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager-vpnc (Ubuntu Yakkety):
status: New → Confirmed
Simon Quigley (tsimonq2)
no longer affects: network-manager-applet (Ubuntu Utopic)
no longer affects: network-manager-openconnect (Ubuntu Utopic)
no longer affects: network-manager-openvpn (Ubuntu Utopic)
no longer affects: network-manager-vpnc (Ubuntu Utopic)
Revision history for this message
Henry Primeau (hprimeau) wrote :

Running 'killall nm-applet; nohup nm-applet &' in Terminal fixed the VPN connection.

Unfortunately, need to do this each time the computer is shutdown and restarted.

Revision history for this message
Sander Alberink (alberink-stampfini) wrote :

I'm experiencing the same problem: updated to Artful Beta to find that my VPN connection will not activate. The workaround details in https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1297849/comments/195 works, but needs to be done everytime.

Revision history for this message
Thomas (tombl) wrote :

Same for me. My VPN connection no longer works since upgrading from 17.04 to 17.10. The work-around `killall nm-applet; nohup nm-applet &` "fixes" it temporarily...

Dan Streetman (ddstreet)
tags: removed: sts
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.