Bug 1332491 - NetworkManager-openconnect not saving username in dialog
Summary: NetworkManager-openconnect not saving username in dialog
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 31
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Florian Müllner
QA Contact: Fedora Extras Quality Assurance
: 1705711 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2016-05-03 10:46 UTC by Matthias Meier
Modified: 2020-01-13 18:19 UTC (History)
23 users (show)

Fixed In Version: NetworkManager-1.2.4-3.fc24
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-10-15 02:49:53 UTC
thaller: needinfo-

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
GNOME Gitlab GNOME/gnome-shell/issues/2105 None None None 2020-01-13 18:19:07 UTC
freedesktop.org Gitlab NetworkManager NetworkManager issues 328 None None None 2020-01-09 11:26:39 UTC

Description Matthias Meier 2016-05-03 10:46:54 UTC
Description of problem:
When connecting with NetworkManager-openconnect on Fedora 23 and before, the  username and password could be saved. On Fedora 24 (Alpha-7) only the password is saved but the username field is empty, so the username has to be entered each time newly.

Version-Release number of selected component (if applicable):

How reproducible:
Connect to a vpn twice

Steps to Reproduce:
1. enter vpn connection 
2. connect and check password save dialog
3. disconnect and connect again

Actual results:
username is not shown in dialog (only password bullets)
login failed is shown if connecting witout entering the username again.

Expected results:
username should be shown as well 

Additional info:

Comment 1 Robert de Rooy 2016-05-25 07:54:07 UTC
Seeing the same problem here on F24 Beta

$ rpm -qa|grep openconnect

Comment 2 David Woodhouse 2016-05-25 07:56:29 UTC
Going to blame NM itself for this. Will strip the stored username from my own config (it was there before I upgraded) and attempt to reproduce...

Comment 3 David Woodhouse 2016-05-25 07:59:18 UTC
Note: NM-openconnect "makes up" secrets as it goes, to remember the authentication form entries (the 'input' ones, not the 'password' ones which end up being stored via libsecret.

So at the first *authentication*, because the server offers a form named 'main' which has a 'username' field, I end up with the auth-dialog spitting out an extra secret that was never previously known, which (in F23 and previously at least) resulted in:

# grep form: /etc/NetworkManager/system-connections/Intel\ AnyConnect\ VPN 

Comment 4 Matthias Meier 2016-06-23 12:09:09 UTC
The problem still exists in final Fedora 24.

Is there a workaround?

Comment 6 Thomas Haller 2016-07-04 14:39:54 UTC
>> setting-vpn: get the flags property name only up to the first ":" in secret 

According to example from comment 3,


it seems the secret name would be "form:main:username". Wouldn't the patch then lookup for "form-main-flags"? How does that fit with "form:main:password-flags"?
Surely the patch does it right, but the commit message does not explain the meaning of the ':'. It should show concrete examples of what openconnect does, and why we would truncate secret names at a colon.

It seems to me, that NMSettingVpn:get_secret_flags() should instead allow for a missing flags entry, but also consider whether there is an entry in the secrets.

Having a password in the @secrets hash, but no flags in @data, might anyway be considered in inconsistent state. I think, NMSettingVpn should treat "name" as secret if at least one of the following is true:

  - @secrets hash has an entry "name".
  - @data hash has an entry "name" + "-flags".

If the flags entry is missing, it should assume "0".

Above would make sense to me, regardless of any openconnect hacks. Wouldn't that fix the openconnect issue?

Comment 7 David Woodhouse 2016-07-04 15:31:04 UTC
(In reply to Thomas Haller from comment #6)
> It seems to me, that NMSettingVpn:get_secret_flags() should instead allow
> for a missing flags entry, but also consider whether there is an entry in
> the secrets.


> Above would make sense to me, regardless of any openconnect hacks. Wouldn't
> that fix the openconnect issue?

As far as I was aware, that was how it always worked.

Comment 8 David Woodhouse 2016-07-04 15:35:36 UTC
Ah, I had missed the fact that this was known to have been broken in https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1424f249e

An alternative suggestion... let us return *data* from the auth-dialog to be stored for future connections, not just secrets. I can set the flags explicitly then.

Comment 9 Joachim Backes 2016-07-06 06:24:02 UTC
(In reply to Robert de Rooy from comment #1)

Seeing the same problem here with the released F24 (Workstation)


Comment 10 Lubomir Rintel 2016-08-22 10:12:26 UTC
This is what was merged to essentially restore the old behavior: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=9b96bfaa722f3cccf0df3a3bca6e8f227643f94f

While extending the auth helper protocol certainly makes sense, it also takes more work to do and a change in the VPN client as well. We could do that in future, but for now this is probably sufficient.

Comment 11 Lubomir Rintel 2016-08-22 10:13:17 UTC
Released in https://bodhi.fedoraproject.org/updates/FEDORA-2016-fade485364 (1.2.4-2.fc24)

Comment 12 Nurul Huda Mustaqim 2016-09-04 13:57:01 UTC
I faced the same problem on Fedora 24 Workstation

Name        : openconnect
Arch        : x86_64
Epoch       : 0
Version     : 7.07
Release     : 2.fc24

Name        : NetworkManager
Arch        : x86_64
Epoch       : 1
Version     : 1.2.4

Name        : NetworkManager-openconnect
Arch        : x86_64
Epoch       : 0
Version     : 1.2.2
Release     : 1.fc24

Comment 13 David Woodhouse 2016-10-11 15:57:50 UTC
This still isn't working for me with NetworkManager-1.2.4-2.fc24

I provision a network with nmcli, and the 'save_passwords' secret is never set even though the auth-dialog returns it.

If I manually add save_passwords-flags=0 to the vpn.data when provisioning, it does get saved.

Comment 14 Thomas Haller 2016-10-12 10:58:30 UTC
9b96bfaa722f3cccf0df3a3bca6e8f227643f94f was never backported to nm-1-2 branch, and is thus not in any libnm-1.2.* up to now.

I cherry-picked the patch upstream: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=bb45adeda0bf427ada23b09daf970b0757e82d60

Comment 15 Fedora Update System 2016-10-13 04:52:10 UTC
NetworkManager-1.2.4-3.fc24 has been pushed to the Fedora 24 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-2016-9317b4b65b

Comment 16 Matthias Meier 2016-10-14 15:25:46 UTC
Thanks a log David and Thomas, it works with NetworkManager-1.2.4-3.fc24 !

Comment 17 Fedora Update System 2016-10-15 02:49:53 UTC
NetworkManager-1.2.4-3.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 David Woodhouse 2019-08-07 09:54:36 UTC
According to https://bugs.launchpad.net/bugs/1609700 this bug has reoccurred in f30.

Comment 19 David Woodhouse 2019-08-08 06:15:26 UTC
*** Bug 1705711 has been marked as a duplicate of this bug. ***

Comment 20 David Woodhouse 2019-08-08 08:14:22 UTC
I wonder if this regression is caused by https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=009f7560867e939 ?

Comment 21 David Woodhouse 2019-08-08 08:31:00 UTC
Please test the Fedora 30 build with that commit reverted, at https://koji.fedoraproject.org/koji/taskinfo?taskID=36857342

Comment 22 David Woodhouse 2019-08-08 15:54:50 UTC
That build seems not to fix it. I tried to build locally to bisect, but can't seem to get the local build to work at all. May have to leave this to the NM maintainers.

Comment 23 compubear 2019-10-09 07:29:48 UTC
Just wanted to mention that this 'bug/issue' is also present in the current Fedora 31 beta with the following packages:


Comment 24 Etienne CHAMPETIER 2019-11-19 19:03:51 UTC
This is happening to me with F31 and some Anyconnect VPNs


My workaround:
nmcli con mod VPNNAME vpn.secrets 'form:main:group_list=GROUPNAME','form:main:username=USERNAME','save_passwords=yes'

Comment 25 udayb 2019-11-22 11:53:40 UTC
This is happening to me with F30 with the latest updates as of date.


Comment 26 Thomas Haller 2020-01-11 07:56:21 UTC
I don't think it's helpful to reopen bugs that were closed for years.

The original issue was identified and confirmed to be fixed.

It's unlikely that the new symptoms have the same cause as the original one. But even so, it would require information to understand the new symptoms better. 

Let's discuss this on https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/328.

Comment 27 David Woodhouse 2020-01-13 18:19:08 UTC
Now https://gitlab.gnome.org/GNOME/gnome-shell/issues/2105

Note You need to log in before you can comment on or make changes to this bug.