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

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

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.

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?

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

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

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

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).

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'.

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

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

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

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

I have the same problem on Ubuntu 14.10

Also experiencing the same thing on 14.04.

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

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

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.

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.

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 ?

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

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..

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.

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

It works for me even after reboot.

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.

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?

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

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.

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

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

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.

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

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.

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

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...

@ #38 : your problem is different

#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 :(

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

steps at #40 worked for me - thanks

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

Thank You!
Keith

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.

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.

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...

run :
restart dbus to resolve issue when it happens.

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

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?

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...

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

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

Running "openconnect" manually works as before.

#34 worked for me, thanks much!

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

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

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.

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

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

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...

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

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.

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.

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.]

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 :(

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 :(

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.

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

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.

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

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.

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.

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.

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.

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.

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

$ sudo restart rsyslog

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

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.

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.

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!

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

@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.

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.

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

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.

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

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.

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...?

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?

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

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.

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.

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.

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

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.

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...

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

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

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

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)

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.

thanks @timxx

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

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.

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.

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.

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.

A PPA with a possible fix would be greatly appreciated.

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
...

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"

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

Please try again.

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

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

this is the patch.

https://launchpadlibrarian.net/202579115/network-manager-applet_0.9.8.8-0ubuntu7_0.9.8.8-0ubuntu8~fixed.diff.gz

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.

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?

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

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.

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.

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.

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.

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)

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.

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.

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.

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.

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.

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.

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?

@Lonnie,

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

nm-applet :

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

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!

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.

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 :(

Lonnie, did you install updates before you tried it?

@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 . . .

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.

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.

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

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.

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.

@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.

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

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.

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.

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?

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).

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

@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

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

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!!

Ubuntu 15.04 (vivid) still affected.

@Roman, have you tried to reboot?

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

Thanks

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 ...

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)

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.

@Mathieu,

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

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.

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

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?

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.

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!

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.

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.

Can you please provide the logs?

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

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?

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

@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?

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.

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

@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.

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

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.

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.

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.

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,

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!

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

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

Works for me, marking as verification-done.

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?

@6-dennis: Maybe you can try

System Settings - Software & Updates - Developer Options

There is an option of 'xenial-proposed'

In Xenial

on testing

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

Works fine.

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

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?

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

(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...

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

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.

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

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

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.

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.

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...