Description of problem: Unable to connect to saved VPN connection, always asked for user password. Newly created VPN connection won't store passwords also. When watching keyring via seahorse, item is created after connecting but also after disconnection immediatelly deleted. Was working before upgrade on Fedora 30. Using Cinnamon desktop. Version-Release number of selected component (if applicable): NetworkManager.x86_64 1:1.20.4-1.fc31 @fedora gnome-keyring.x86_64 3.34.0-1.fc31 @fedora How reproducible: Connect to existing VPN connection via network manager icon in tray Steps to Reproduce: 1. Select saved VPN connection from networkmanager systray with saved user password Actual results: User password promt opens without possibility to save password Expected results: No password promt, connection established Additional info: Updated to Fedora 31 from Fedora 30 using DNF plugin
I have the exact same issue using XFCE following an upgrade from fc30 to fc31 today, also using the dnf plugin. RPMs: gnome-keyring-3.34.0-1.fc31.x86_64 gnome-keyring-pam-3.34.0-1.fc31.x86_64 libgnome-keyring-3.12.0-18.fc31.x86_64 gnome-keyring-sharp-1.0.1-0.29.133722svn.fc31.x86_64 Invoking seahorse (aka 'Passwords and keys'), it's showing that the logon and default keyrings did not get unlocked at login. Manually unlocking from seahorse, reveals (at least some of) the previously saved VPN passwords. However, even after doing such a manual unlock, NetworkManager still prompts for passwords for each and every saved VPN connection but does not retain them thereafter. Prior behaviour under fc30 was that, once provided, a vpn password would be memorised and no longer prompted for on subsequent invocations of the connection.
Identical case in the fact that all my VPN connections now ask for the password (all of them are IPSec with EAP having username and password). Before the upgrade from F30 it did work. And yes, keyrinhg is open, seahorse sees the passwords, other apps like Remmina have no problem reading them - so this must be NM. Have not tried with a new connection (wasted enough time on this bug anyway). Opened a bug report 1767980, but responding here also in hope somebody pays attention.
FEDORA-2019-dd4b4a67f4 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd4b4a67f4
NetworkManager-1.20.6-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-dd4b4a67f4
( This comment is purely as concerns my personal installations - other people may have found that the new rpms fix the issue. ) 1) Unfortunately, the updates-testing rpms do not fix this bug for me personally. The behaviour on fc31 remains as before, albeit that there is perhaps a slightly longer delay before the password prompt appears. 'dnf history info nnn' output from my vanilla fc31 virtualbox install : Transaction ID : 6 Begin time : Thu 07 Nov 2019 14:47:47 GMT Begin rpmdb : 1468:3010893ac1e20f3d1ffce11fcdf19c873a464c8d End time : Thu 07 Nov 2019 14:47:55 GMT (8 seconds) End rpmdb : 1468:469fdcc37fd71ee8b7cbdd6ccea62cc33f9f9f6a User : giain <giain> Return-Code : Success Releasever : 31 Command Line : upgrade --enablerepo=updates-testing --advisory=FEDORA-2019-dd4b4a67f4 Packages Altered: Upgrade NetworkManager-1:1.20.6-1.fc31.x86_64 @updates-testing Upgraded NetworkManager-1:1.20.4-1.fc31.x86_64 @@System Upgrade NetworkManager-adsl-1:1.20.6-1.fc31.x86_64 @updates-testing Upgraded NetworkManager-adsl-1:1.20.4-1.fc31.x86_64 @@System Upgrade NetworkManager-bluetooth-1:1.20.6-1.fc31.x86_64 @updates-testing Upgraded NetworkManager-bluetooth-1:1.20.4-1.fc31.x86_64 @@System Upgrade NetworkManager-libnm-1:1.20.6-1.fc31.x86_64 @updates-testing Upgraded NetworkManager-libnm-1:1.20.4-1.fc31.x86_64 @@System Upgrade NetworkManager-ppp-1:1.20.6-1.fc31.x86_64 @updates-testing Upgraded NetworkManager-ppp-1:1.20.4-1.fc31.x86_64 @@System Upgrade NetworkManager-team-1:1.20.6-1.fc31.x86_64 @updates-testing Upgraded NetworkManager-team-1:1.20.4-1.fc31.x86_64 @@System Upgrade NetworkManager-wifi-1:1.20.6-1.fc31.x86_64 @updates-testing Upgraded NetworkManager-wifi-1:1.20.4-1.fc31.x86_64 @@System Upgrade NetworkManager-wwan-1:1.20.6-1.fc31.x86_64 @updates-testing Upgraded NetworkManager-wwan-1:1.20.4-1.fc31.x86_64 @@System Just to add if it helps to analyse: 2) This bug is <not> apparent for me in fc32 (rawhide) running on virtualbox and with essentially same-versioned rpms as fc31 : gnome-keyring-pam-3.34.0-1.fc32.x86_64 gnome-keyring-3.34.0-1.fc32.x86_64 NetworkManager-1.20.4-1.fc32.x86_64 NetworkManager-openvpn-1.8.10-1.fc31.1.x86_64 etc. However, on both my desktop and laptop, which are upgraded xfce fc30->fc31 installations (both using lightdm) and also in a fc31 virtualbox new install from the live xfce 'cd', which I tried as a test yesterday (i.e. three separate fc31 systems), the bug is present and remains so after the updates-testing rpms were installed. 3) On the fc31 installations, the following appears to happen in my case: i) nm does not properly read the saved secret when selecting an existing vpn connection ii) if you ignore the resulting password dialog box and press cancel, it then deletes the actual saved secret from the keyring iii) however, if you enter the password it will then proceed to connect as normal and will apparently save the password in the keyring (or perhaps not delete the existing one). Hence, taking the uuid from a VPN config in /etc/NetworkManager/system-connections/ and using that in a 'secret-tool lookup connection-uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' command (where xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx is the hex uuid string) you get the password returned, proving it's there. Invoking that same VPN config from the NetworkManager gui (or nmcli / nmtui), however, brings up the password prompt.
NetworkManager-1.20.6-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Bournonville from comment #5) > [...] > 3) On the fc31 installations, the following appears to happen in my case: > > i) nm does not properly read the saved secret when selecting an existing > vpn connection > ii) if you ignore the resulting password dialog box and press cancel, it > then deletes the actual saved secret from the keyring > iii) however, if you enter the password it will then proceed to connect as > normal and will apparently save the password in the keyring (or perhaps not > delete the existing one). > > Hence, taking the uuid from a VPN config in > /etc/NetworkManager/system-connections/ and using that in a 'secret-tool > lookup connection-uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' command (where > xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx is the hex uuid string) you get the > password returned, proving it's there. > > Invoking that same VPN config from the NetworkManager gui (or nmcli / > nmtui), however, brings up the password prompt. If you are using the nm-applet and/or nm-connection-editor, can you try this package from the updates-testing repository? https://bodhi.fedoraproject.org/updates/FEDORA-2019-756adb2f28
(In reply to Beniamino Galvani from comment #7) > (In reply to Bournonville from comment #5) > > [...] > > 3) On the fc31 installations, the following appears to happen in my case: > > > > i) nm does not properly read the saved secret when selecting an existing > > vpn connection > > ii) if you ignore the resulting password dialog box and press cancel, it > > then deletes the actual saved secret from the keyring > > iii) however, if you enter the password it will then proceed to connect as > > normal and will apparently save the password in the keyring (or perhaps not > > delete the existing one). > > > > Hence, taking the uuid from a VPN config in > > /etc/NetworkManager/system-connections/ and using that in a 'secret-tool > > lookup connection-uuid xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' command (where > > xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx is the hex uuid string) you get the > > password returned, proving it's there. > > > > Invoking that same VPN config from the NetworkManager gui (or nmcli / > > nmtui), however, brings up the password prompt. > > If you are using the nm-applet and/or nm-connection-editor, can you try this > package from the updates-testing repository? > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-756adb2f28 Yes, this does seem to have fixed the issue for me thank you. Packages Altered: Upgrade libnma-1.8.24-1.fc31.x86_64 @updates-testing Upgraded libnma-1.8.22-1.fc31.1.x86_64 @@System Upgrade network-manager-applet-1.8.24-1.fc31.x86_64 @updates-testing Upgraded network-manager-applet-1.8.22-1.fc31.1.x86_64 @@System Upgrade nm-connection-editor-1.8.24-1.fc31.x86_64 @updates-testing Upgraded nm-connection-editor-1.8.22-1.fc31.1.x86_64 @@System