Description of problem: The group password for a vpnc connection can be saved (grou password: saved, password: not saved), but when I actually try to connect to the VPN and I get prompted for my password and the group password, the group password is not beeing used. Version-Release number of selected component (if applicable): F16 - but heard that it's the same on F18 beta
I'm still hitting this on Fedora 18 under Xfce. I understand that it works fine in Gnome 3.x, but not under Xfce or KDE or other desktops. I also noticed this in my /var/log/messages. I'm not sure if it's related: Jan 28 08:22:44 tarantula gnome-keyring-daemon[1677]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files Jan 28 08:22:44 tarantula gnome-keyring-daemon[1677]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files Jan 28 08:22:44 tarantula gnome-keyring-daemon[1677]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files
I'm seeing that too on Fedora 17 with openbox. I stored vpnc group password. However when connecting, the dialogs ask for that. I guess it's co-operation issue with gnome-keyring and desktop session. $ rpm -q gnome-keyring gnome-keyring-3.4.1-4.fc17.x86_64 /var/log/messages: Jan 29 12:58:14 localhost gnome-keyring-daemon[19954]: couldn't access conrol socket: /run/user/jklimes/keyring-MKJMFh/control: No such file or directory Jan 29 12:58:15 localhost gnome-keyring-daemon[19954]: couldn't set environment variable in session: The name org.gnome.SessionManager was not provided by any .service files Jan 29 12:58:15 localhost gcr-prompter[19962]: Gcr: the prepared data does not have the correct protocol prefix Jan 29 12:58:15 localhost gnome-keyring-daemon[19954]: Gcr: the prepared data does not have the correct protocol prefix Jan 29 12:58:19 localhost gcr-prompter[19962]: Gcr: the prepared data does not have the correct protocol prefix Jan 29 12:58:19 localhost gnome-keyring-daemon[19954]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk $ env | grep KEYRING GNOME_KEYRING_CONTROL=/run/user/jklimes/keyring-MKJMFh GNOME_KEYRING_PID=1512 Apparently, the environment variables are wrong. It could be related with https://bugzilla.redhat.com/show_bug.cgi?id=783568 See also https://bugs.launchpad.net/linuxmint/+bug/1011593 Reassigning to gnome-keyring for now.
(In reply to comment #2) > I'm seeing that too on Fedora 17 with openbox. I stored vpnc group password. > However when connecting, the dialogs ask for that. Please use 'seahorse' to see whether the password has been stored in your keyring or not. Does this occur when you don't use openbox? > /var/log/messages: > Jan 29 12:58:14 localhost gnome-keyring-daemon[19954]: couldn't access > conrol socket: /run/user/jklimes/keyring-MKJMFh/control: No such file or > directory > Jan 29 12:58:15 localhost gnome-keyring-daemon[19954]: couldn't set > environment variable in session: The name org.gnome.SessionManager was not > provided by any .service files > Jan 29 12:58:15 localhost gcr-prompter[19962]: Gcr: the prepared data does > not have the correct protocol prefix > Jan 29 12:58:15 localhost gnome-keyring-daemon[19954]: Gcr: the prepared > data does not have the correct protocol prefix > Jan 29 12:58:19 localhost gcr-prompter[19962]: Gcr: the prepared data does > not have the correct protocol prefix > Jan 29 12:58:19 localhost gnome-keyring-daemon[19954]: couldn't allocate > secure memory to keep passwords and or keys from being written to the disk These messages are unfortunately not related. They have been fixed in gnome-keyring 3.6 and later. > $ env | grep KEYRING > GNOME_KEYRING_CONTROL=/run/user/jklimes/keyring-MKJMFh > GNOME_KEYRING_PID=1512 > > Apparently, the environment variables are wrong. gnome-keyring is accessed by clients using the DBus session, not environment variables. > It could be related with https://bugzilla.redhat.com/show_bug.cgi?id=783568 > > See also https://bugs.launchpad.net/linuxmint/+bug/1011593 FWIW, this is not related to that innocuous but annoying warning.
seahorse shows the vpnc group password for me. And in fact, if I right-click on nm-applet and go to Edit Connections, select the VPN connection, and click Edit, then it shows the correct group password. I then changed the password and went back to seahorse and verified that seahorse had the new password. The only problem is when I try to connect, the group password is blank.
So it's being stored, but not loaded by network-manager-applet? I guess a network manager developer would know how to make nm-applet provide appropriate debug output, so you can discover why it's not loading the file. Or perhaps you know how to do this? Admitedly you are using a rather non-standard session. If you do discover a bug, or possible isssue, I'm all ears, but it's hard to troubleshoot such a session remotely.
I just tried an experiment: I created a new VPN connection under Xfce named "xfce-vpn" (with fake info), then I logged out of Xfce, and logged into Gnome, and created another VPN named "gnome-vpn" (with the same fake info). I then tried to use both VPN connections under both desktops. Gnome desktop + gnome-vpn = success (it did not ask for the group password) Gnome desktop + xfce-vpn = success Xfce desktop + gnome-vpn = success Xfce desktop + xfce-vpn = FAIL So nm-applet and/or gnome-keyring is doing something odd when it creates a new VPN connection when running in a non-Gnome desktop.
Ignore my comment 6. Creating the VPN connection under different desktops was not the cause. Rather, it appears to be how gnome-keyring is started under Xfce. On a fresh login to Xfce, I get: $ pgrep -lf gnome-key 1280 /usr/bin/gnome-keyring-daemon --daemonize --login I try to connect to the VPN and it asks for the group password. But I hit Cancel instead of connecting. Check the processes again: $ pgrep -lf gnome-key 1280 /usr/bin/gnome-keyring-daemon --daemonize --login 1699 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets Hmm, a new daemon was started. I try the VPN again and this time it does NOT ask for the group password. Hooray! (So in comment 6, I tested Xfce + xfce-vpn first and it failed, then I tried gnome-vpn second and it worked because the second gnome-keyring-daemon had started.)
(In reply to comment #7) > Ignore my comment 6. Creating the VPN connection under different desktops > was not the cause. > > Rather, it appears to be how gnome-keyring is started under Xfce. > > On a fresh login to Xfce, I get: > $ pgrep -lf gnome-key > 1280 /usr/bin/gnome-keyring-daemon --daemonize --login This is the gnome-keyring-daemon started by GDM. It needs to be later initialized by another instance of gnome-keyring-daemon. The GNOME_KEYRING_CONTROL environment variable is used to do this. If the second instance of gnome-keyring-daemon cannot talk to the first (likely due to a missing GNOME_KEYRING_CONTROL env var), then it'll hang around and process requests. Some more details: https://live.gnome.org/GnomeKeyring/RunningDaemon
(In reply to comment #8) > likely due to a missing GNOME_KEYRING_CONTROL env var I think that's the root of the problem: $ env | grep GNOME $ I've tried various things like turning on Xfce's "Launch GNOME services on startup" (under Session and Startup -> Advanced) and I installed the gnome-keyring-pam package which should setup the environment, but still no luck. The environment just doesn't have the variables set.
Hmmm, that's really very strange. Because those environment variables come from the gnome-keyring pam module, and it uses standard PAM calls to modify the environment. Nothing magical here. I guess the next step is to check that the /etc/pam.d/gdm config includes the gnome-keyring module.
Sorry for the noise... Just wanted to mention, that it's worth noting that gnome-keyring can operate without the PAM module and the GNOME_KEYRING environment variables. The PAM module is simply used to unlock the 'login' keyring with your unix user login password. Also, obviously /etc/pam.d/gdm does contain the gnome-keyring module, as the process above is being started by it: 1280 /usr/bin/gnome-keyring-daemon --daemonize --login So maybe another step would be to try disabling the PAM module, and let gnome-keyring be autostarted by DBus on the first usage?
I've tried both gdm and lightdm and I don't get the environment variables set. Both the /etc/pam.d/gdm* and /etc/pam.d/lightdm files include lines for gnome-keyring-pam. I also tried removing the gnome-keyring-pam package and it still it doesn't work. The daemon does get started, but nm-applet won't populate the group password. And yet if I go to Edit Connections in nm-applet, it can read the group password just fine. The really odd part is I have another system which I did a fedup upgrade from Fedora 17 to Fedora 18 and nm-applet works just fine on that system. It's only this box which is a fresh clean install of F18 where I have problems with the group password. Maybe I should downgrade to F17, get everything working, and then fedup it. :)
I just tried manually setting the env vars and restarting nm-applet to make sure that nm-applet has the proper environment: $ pkill nm-applet $ pgrep -lf keyring 1637 /usr/bin/gnome-keyring-daemon --daemonize --login 1807 gnome-keyring-daemon --start $ export GNOME_KEYRING_PID=1637 $ export GNOME_KEYRING_CONTROL=$(echo /run/user/1000/keyring-*) $ nm-applet & [1] 2080 $ cat /proc/2080/environ | tr '\000' '\n' | grep RING GNOME_KEYRING_CONTROL=/run/user/1000/keyring-yxIqPf GNOME_KEYRING_PID=1637 But no luck: it still asks for the VPN group password.
What is the output of 'ldd $(which nm-applet)'
$ ldd $(which nm-applet) linux-vdso.so.1 => (0x00007fffe29ff000) libm.so.6 => /lib64/libm.so.6 (0x0000003cd6400000) libnotify.so.4 => /lib64/libnotify.so.4 (0x0000003c0c400000) libnm-gtk.so.0 => /lib64/libnm-gtk.so.0 (0x0000003c0d000000) libgnome-keyring.so.0 => /lib64/libgnome-keyring.so.0 (0x0000003c0cc00000) libgudev-1.0.so.0 => /lib64/libgudev-1.0.so.0 (0x0000003c0b800000) libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x0000003c0ac00000) libgdk-3.so.0 => /lib64/libgdk-3.so.0 (0x0000003c0a000000) libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x0000003c08c00000) libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x0000003c08800000) libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x0000003c08400000) libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 (0x0000003c0b400000) libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x0000003c09400000) libcairo.so.2 => /lib64/libcairo.so.2 (0x0000003704a00000) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x0000003c07c00000) libnm-glib.so.4 => /lib64/libnm-glib.so.4 (0x0000003c0bc00000) libnm-util.so.2 => /lib64/libnm-util.so.2 (0x0000003c0a800000) libnm-glib-vpn.so.1 => /lib64/libnm-glib-vpn.so.1 (0x0000003c0c800000) libdbus-glib-1.so.2 => /lib64/libdbus-glib-1.so.2 (0x0000003c09800000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x0000003cda800000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003c07400000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003c07000000) librt.so.1 => /lib64/librt.so.1 (0x0000003cd5c00000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003c06c00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003cd5800000) libc.so.6 => /lib64/libc.so.6 (0x0000003cd5000000) libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x0000003cebc00000) libudev.so.1 => /lib64/libudev.so.1 (0x0000003cda000000) libsystemd-daemon.so.0 => /lib64/libsystemd-daemon.so.0 (0x0000003cd9400000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003cd5400000) libX11.so.6 => /lib64/libX11.so.6 (0x0000003cda400000) libXi.so.6 => /lib64/libXi.so.6 (0x0000003cdd400000) libXfixes.so.3 => /lib64/libXfixes.so.3 (0x0000003cdc800000) libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x0000003c09c00000) libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x0000003c08000000) libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x0000003cdc400000) libXinerama.so.1 => /lib64/libXinerama.so.1 (0x0000003ce3c00000) libXrandr.so.2 => /lib64/libXrandr.so.2 (0x0000003cdfc00000) libXcursor.so.1 => /lib64/libXcursor.so.1 (0x0000003ce0400000) libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x0000003ce5c00000) libXdamage.so.1 => /lib64/libXdamage.so.1 (0x0000003ce5400000) libXext.so.6 => /lib64/libXext.so.6 (0x0000003cdbc00000) libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x0000003c09000000) libfreetype.so.6 => /lib64/libfreetype.so.6 (0x0000003cdb800000) libpng15.so.15 => /lib64/libpng15.so.15 (0x0000003cdac00000) libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x0000003ce3400000) libEGL.so.1 => /lib64/libEGL.so.1 (0x0000003704e00000) libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x0000003ce0c00000) libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x0000003ce1000000) libxcb.so.1 => /lib64/libxcb.so.1 (0x0000003cd9c00000) libXrender.so.1 => /lib64/libXrender.so.1 (0x0000003cdd000000) libz.so.1 => /lib64/libz.so.1 (0x0000003cd6000000) libGL.so.1 => /lib64/libGL.so.1 (0x0000003704200000) libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x0000003c07800000) libffi.so.5 => /lib64/libffi.so.5 (0x0000003cd8400000) libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003cd6c00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003cd7400000) libuuid.so.1 => /lib64/libuuid.so.1 (0x0000003cdc000000) libssl3.so => /lib64/libssl3.so (0x0000003ceb000000) libsmime3.so => /lib64/libsmime3.so (0x0000003cec000000) libnss3.so => /lib64/libnss3.so (0x0000003ce8c00000) libnssutil3.so => /lib64/libnssutil3.so (0x0000003ce8000000) libplds4.so => /lib64/libplds4.so (0x0000003ce7800000) libplc4.so => /lib64/libplc4.so (0x0000003ce7000000) libnspr4.so => /lib64/libnspr4.so (0x0000003ce7400000) /lib64/ld-linux-x86-64.so.2 (0x0000003cd4c00000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x0000003ceac00000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003cd7000000) libatspi.so.0 => /lib64/libatspi.so.0 (0x0000003c0a400000) libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003cdb000000) libicule.so.49 => /lib64/libicule.so.49 (0x0000003ce1c00000) libicuuc.so.49 => /lib64/libicuuc.so.49 (0x0000003ce2400000) libicudata.so.49 => /lib64/libicudata.so.49 (0x0000003cddc00000) libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x0000003cdcc00000) libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x0000003ce0000000) libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x0000003ce3000000) libxcb-shape.so.0 => /lib64/libxcb-shape.so.0 (0x0000003ce4c00000) libwayland-client.so.0 => /lib64/libwayland-client.so.0 (0x0000003ce3800000) libwayland-server.so.0 => /lib64/libwayland-server.so.0 (0x0000003ce5800000) libgbm.so.1 => /lib64/libgbm.so.1 (0x0000003ce1400000) libglapi.so.0 => /lib64/libglapi.so.0 (0x0000003ce5000000) libdrm.so.2 => /lib64/libdrm.so.2 (0x0000003703e00000) libXau.so.6 => /lib64/libXau.so.6 (0x0000003cd9800000) libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x0000003ce0800000) libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x0000003ce4400000) libpcre.so.1 => /lib64/libpcre.so.1 (0x0000003cd6800000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003cd9000000)
Do you think this might be related to bug #907156
Hmm, it could be. When I first try to connect to VPN after logging in to Xfce, I get a gnome-keyring pop-up saying something like "the login keyring wasn't unlocked, enter your keyring password". Then the VPN password dialog pops up (but the group password is blank) Once the login keyring is unlocked, the VPN goes straight to the VPN password dialog where the group password is still blank.
I also tried using Seahorse to unlock the login keyring before attempting to connect to VPN. This did solve the gnome-keyring password dialog, but the VPN group password was still blank.
Been seeing this for a while. I was never able to find the a bz for it though. Glad to have finally found it. Anyway, also seeing this on F17/Xfce.
It's working fine for me with XFCE. No idea about gnome.
(In reply to comment #18) > I also tried using Seahorse to unlock the login keyring before attempting to > connect to VPN. This did solve the gnome-keyring password dialog, but the > VPN group password was still blank. When you run seahorse, can you find the group password in one of your keyrings? It's always stored in the default keyring, so whatever gnome-keyring decides is the default keyring is where the NM-vpnc looks for it. When you have auto-unlock set up, I believe that's the "login" keyring, no the "default" keyring (yes, confusingly named). You'll see it as "VPN group-password secret for <your VPN name>/org.freedesktop.NetworkManager.vpnc/vpn".
Yes, my keyring has the group password according to seahorse. And it works under Gnome, just not Xfce, so Gnome can read the group password somehow. In fact, when I have seahorse running and I try to connect to the VPN, the group password in seahorse blinks when nm-applet tries to read the password. In my troubleshooting efforst, I also noticed the "Default" vs "Login" keyrings. I had "Default" originally (since I started with the Xfce spin), so I deleted it and created a "Login" keyring and made it the default, but that didn't help. The name of the entry in seahorse is slightly different, however: VPN IPSec secret secret for <VPN-name>/org.freedesktop.NetworkManager.vpnc/vpn That is, instead of "group-password" I have "IPSec secret"
I ran dbus-monitor while trying to connect to the VPN and I see it searching for both "IPSec secret" and "group-password": [jbastian@localhost ~]$ dbus-monitor interface=org.freedesktop.Secret.Service,member=SearchItems signal sender=org.freedesktop.DBus -> dest=:1.96 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.96" method call sender=:1.97 -> dest=org.freedesktop.secrets serial=4 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems array [ dict entry( string "connection-uuid" string "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" ) dict entry( string "setting-name" string "vpn" ) dict entry( string "setting-key" string "IPSec secret" ) ] method call sender=:1.64 -> dest=org.freedesktop.secrets serial=37 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems array [ dict entry( string "connection-uuid" string "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" ) ] method call sender=:1.98 -> dest=org.freedesktop.secrets serial=4 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems array [ dict entry( string "connection-uuid" string "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" ) dict entry( string "setting-name" string "vpn" ) dict entry( string "setting-key" string "IPSec secret" ) ] method call sender=:1.98 -> dest=org.freedesktop.secrets serial=5 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems array [ dict entry( string "connection-uuid" string "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" ) dict entry( string "setting-name" string "vpn" ) dict entry( string "setting-key" string "group-password" ) ]
I see Ubuntu users are having this problem too: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1043043
I've finally updated to Fedora 18 and the problem is gone. The group password is saved (as configured in the UI) and NM asks for the (user) password.
Re-opening: this is not fixed for me on Fedora 18 Xfce (as I mentioned in comment 1) and NetworkManager-0.9.8.0-1.fc18.x86_64 NetworkManager-vpnc-0.9.3.997-3.fc18.x86_64 dbus-1.6.8-2.fc18.x86_64 gnome-keyring-3.6.3-1.fc18.x86_64 gnome-keyring-pam-3.6.3-1.fc18.x86_64
Created attachment 712266 [details] screenshot of blank group password This screenshot shows 3 windows: 1. NetworkManager Edit Connections showing the group password is set to Saved 2. Seahorse showing the keyring with the saved group password 3. NetworkManager asking for the group password anyway when I try to connect
*** Bug 887984 has been marked as a duplicate of this bug. ***
I'm seeing this as well, Fedora 18, MATE desktop. I also seem to have had it forget the group password entirely, but I'm not sure of what the conditions were which triggered that
I've observed that sometimes it does seem to work correctly, displaying a dialog with only one password prompt. I haven't yet discerned any pattern as to when this happens, and when it displays the dialog with two password boxes, neither filled in from the saved information. NetworkManager-vpnc-0.9.3.997-3.fc18.x86_64
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The problem is still present in Fedora 18, changing the version tag.
I'm hitting this issue with XFCE using vpnc on F19 (no gnome desktop installed). My vpn config specifies to ask for the user password and has a saved group password. When I use the nm applet to start the vpnc connection, it asks for the user password (good) *and* the group password (bad). Supplying both starts the vpn connection but obviously I shouldn't have to supply the group password. Checking the keyring with Seahorse under Passwords/default shows an entry with description "VPN IPSec secret secret for BNE/org.freedesktop.NetworkManager.vpnc/vpn". The password value in that entry shows the correct group password, as config'd earlier. Is the "secret secret" bit a typo or something? Maybe that has something to do with dbus or whatever not finding the group-password key? Should it be "group-password secret" perhaps? Versions: NetworkManager-0.9.8.2-5.fc19.x86_64 NetworkManager-vpnc-0.9.3.997-4.fc19.x86_64 dbus-1.6.12-1.fc19.x86_64 gnome-keyring-3.8.2-1.fc19.x86_64 Regards -- Mark
Hi All, Having the same issue with F19 NetworkManager-openvpn-0.9.8.2-3.fc19.x86_64 NetworkManager-vpnc-0.9.8.2-2.fc19.x86_64 NetworkManager-openvpn-gnome-0.9.8.2-3.fc19.x86_64 NetworkManager-vpnc-gnome-0.9.8.2-2.fc19.x86_64 NetworkManager-glib-0.9.8.2-9.git20130709.fc19.x86_64 NetworkManager-pptp-gnome-0.9.8.2-3.fc19.x86_64 NetworkManager-0.9.8.2-9.git20130709.fc19.x86_64 NetworkManager-pptp-0.9.8.2-3.fc19.x86_64 A workaround is the following: cd /etc/NetworkManager/system-connections/ vim <You-VPN-Connection-Name> s/IPSec secret-flags=0/IPSec secret-flags=1 (Ref: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1043043/comments/34) However this is a manual workaround. Best Regards, TK
Correcting the above s/IPSec secret-flags=1/IPSec secret-flags=0 IPSec secret-flags=1 by default and you need to change it to 0 NOT vice versa. BR TK
(In reply to Theophanis Kontogiannis from comment #35) > Correcting the above > > s/IPSec secret-flags=1/IPSec secret-flags=0 > > IPSec secret-flags=1 by default and you need to change it to 0 > > NOT vice versa. > Thanks for that, I was getting rather sick of typing in the group password. Verified on f19 / XFCE / NetworkManager-0.9.8.2-9.git20130709.fc19.x86_64
I just started having this problem using F20 on GNOME (NetworkManager version 1:0.9.9.0-31.git20131003.fc20). I'm prompted each time for the group password but it's never saved (even when I add it directly in the NetworkManager settings). I checked my keyring and the Gnome 2 Key Storage is locked. Not sure why it's not being unlocked but my login password (which hasn't changed in a while) doesn't work.
Confirming that this still happens on F20 on MATE with NetworkManager-vpnc-0.9.8.2-2.fc20.x86_64.rpm. The group password is saved, but it still prompts for both passwords when connecting. I noticed it would prompt for the group password on the first connection. Subsequent disconnects/connects often would only prompt for the user password. Lately however it seems to prompt for both passwords every time, even though the group password is "saved". Also confirming that the work-around from comment #35 seems to work for me on F20 and MATE, although with limited testing. (Thanks, Theophanis!) I suspect the problem is that mixed password saved status on vpn connection creation/edit causes the wrong value to be stored for "IPSec secret-flags" in /etc/NetworkManager/system-connections/{Connection_name}.
What other consequences does that woarkaround have? Is that option documented anywhere?
Just ran into this, nothing useful to add but this bump. Fedora 20, xfce, NetworkManager-vpnc-0.9.8.2-2.fc20.x86_64 I'm on aricg on freenode, I'd be happy to help test a patch.
The workaround in comment 35 works for me. Thanks! Fam
(In reply to David Gibson from comment #39) > What other consequences does that woarkaround have? > > Is that option documented anywhere? They are documented in the NM settings, for example 'man nm-settings' on recent versions of NM. The "-flags" variables control where the secret is stored, and how it's used: Secret flag types: Each secret property in a setting has an associated flags property that describes how to handle that secret. The flags property is a bitfield that contains zero or more of the following values logically OR-ed together. · 0x0 (none) - the system is responsible for providing and storing this secret. · 0x1 (agent-owned) - a user-session secret agent is responsible for providing and storing this secret; when it is required, agents will be asked to provide it. · 0x2 (not-saved) - this secret should not be saved but should be requested from the user each time it is required. This flag should be used for One-Time-Pad secrets, PIN codes from hardware tokens, or if the user simply does not want to save the secret. · 0x4 (not-required) - in some situations it cannot be automatically determined that a secret is required or not. This flag hints that the secret is not required and should not be requested from the user. So when you change it from "1" to "0", you are saying "save this secret in /etc not in the user's keyring".
Thanks for that information. Fwiw, "IPSec secret-flags" is not listed by that name in the man page, so it's not obvious from that alone that it falls in the category of "Secret flag types" which are described. Why is getting this setting correct from the checkbox which ought to control it in the GUI so difficult that it hasn't been fixed yet?
Having a similar (the same) issue in F21. The group-password is set to "saved", yet, is prompted for and next time I open the dialog the entry field for group password is empty.
Please consider adding an option in the GUI for "IPSec secret-flags", and confirm the availability of secret agent before defaulting to 0x1. If there isn't one, probably this option should be disabled and fall back to 0x0 with a warning message.
(In reply to Fam Zheng from comment #45) > Please consider adding an option in the GUI for "IPSec secret-flags", and > confirm the availability of secret agent before defaulting to 0x1. If there > isn't one, probably this option should be disabled and fall back to 0x0 with > a warning message. I do not understand the relation between secret-flags and the password not being saved and may even misunderstand what you propose, but in my opinion no situation of any sort (secret-flags 0x1 or 0x0) will justify the fact that the user chooses to "Save password" and yet, the password is forgotten from the entry-widget and is asked for upon connect. I think the whole idea of choosing "Save password" in the preferences is inconsistent with how passwords are treated in general in the first place. The "semantically correct" way should be that the keyring handles that. I.e.: The dialog which asks for a password offers a "remember password" checkbox which will store the credentials into the keyring. Whenever there is a password in the keyring for a given account, it *will* be used. At least that seems to be the usual way how things work with the keyring?
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
For me, this bug is fixed on Fedora 22.