username is not saved in openconnect connection dialog

[knut]

Happening again on Eoan 19.10!

Hi,

I clicked on "save passwords" but only the password is filled in automatically when I open the connection dialog. The "Username" field is empty!

This happens for a SSLVPN configuration.

For another VPN config (don't know which type) everything is ok.

openconnect: 7.06-2build2

[Matthias (matthias-redhat-bugs)]

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):
 1.2.0-1.fc24

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:

[Robert (robert-redhat-bugs-1)]

Seeing the same problem here on F24 Beta

$ rpm -qa|grep openconnect
openconnect-7.06-4.fc24.x86_64
NetworkManager-openconnect-1.2.2-1.fc24.x86_64

[David (david-redhat-bugs)]

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

[David (david-redhat-bugs)]

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
form:main:password-flags=1
form:main:<email address hidden>

[Matthias (matthias-redhat-bugs)]

The problem still exists in final Fedora 24.

Is there a workaround?

[Lubomir (lubomir-redhat-bugs)]

https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=lr/openconnect-secrets-rh1332491

[Thomas (thomas-redhat-bugs)]

>> setting-vpn: get the flags property name only up to the first ":" in secret

According to example from comment 3,

  form:main:password-flags=1
  form:main:<email address hidden>

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?

[David (david-redhat-bugs)]

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

[David (david-redhat-bugs)]

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.

[Joachim (joachim-redhat-bugs)]

(In reply to Robert de Rooy from comment #1)

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

openconnect-7.06-4.fc24.x86_64
NetworkManager-openconnect-1.2.2-1.fc24.x86_64
NetworkManager-1.2.2-2.fc24.x86_64

[Mike Miller (mtmiller)]

The dialog is network-manager-openconnect. Which versions of network-manager and network-manager-openconnect are installed showing this problem? Is this using KDE, GNOME 3, or another DE?

[berglh (berglh)]

I am experience this same problem in Ubuntu Gnome 16.04.1, it's quite frustrating. I've tried to edit the config file in /etc/NetworkManager/system-connections and manually enter user, username, Xauth user parameters all with no effect. Here are my package versions:

network-manager 1.2.0-0ubuntu0.16.04.3
network-manager-openconnect 1.2.0-0ubuntu0.16.04.1
network-manager-openconnect-gnome 1.2.0-0ubuntu0.16.04.1
openconnect 7.06-2build2
gnome-shell 3.18.5-0ubuntu0.1

The entry in the password and keys (Seahorse I think) saved for the VPN connection does have a details tab that has a value stored as "username_value: myusername". The problem is that this detail isn't populated into the connection correctly. Perhaps it's looking for a different key value to populate than what is saved into the details off the connection?

[knut (mr-knut)]

I use Cinnamon 3.0 (GNOME)

network-manager 1.2.0-0ubuntu0.16.04.3
network-manager-openconnect 1.2.0-0ubuntu0.16.04.1

[Lubomir (lubomir-redhat-bugs)]

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.

[Lubomir (lubomir-redhat-bugs)]

Released in https://bodhi.fedoraproject.org/updates/FEDORA-2016-fade485364 (1.2.4-2.fc24)

[Nurul (nurul-redhat-bugs)]

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

[Hans Rüdiger Hammer (haruehammer)]

I have the same problem. Ubuntu Gnome 16.04:
network-manager 1.2.0-0ubuntu0.16.04.3
network-manager-openconnect 1.2.0-0ubuntu0.16.04.1

I entered this connection after a new install of Ubuntu and the user names does not get saved. However, I have another Ubuntu I upgraded from 15.10, with the connection already entered and correctly stored before the upgrade. There the user name is filled out without problem. So it seems, the user name does not get stored correctly. But once it is, it can be retrieved. I hope that helps.

[Pedro (pedro-lupin)]

Same problem:
Ubuntu Gnome 16.04.1
network-manager 1.2.0-0ubuntu0.16.04.3
network-manager-openconnect-gnome 1.2.0-0ubuntu0.16.04.1
network-manager-openconnect 1.2.0-0ubuntu0.16.04.1

[Sebastian Geiger (lanoxx)]

I can confirm this:

Package: network-manager-openconnect-gnome
Version: 1.2.0-0ubuntu0.16.04.1

On Ubuntu 16.04 (using a GTK based UI)

Its highly annoying since my username is rather long and I need to retype it every time I start the connection. Since the password is correctly saved this is clearly a bug.

[Ivan (ivan-zderadicka)]

Same here - openconnect is completely screwed in 16.04 - not only this, but also other bug with 20 secs timeout which makes it unusable under 16.04.
For me it real show stopper for ubuntu 16.04.

[Hawk (beehock)]

It is also happening in Ubuntu 16.10

[David (david-redhat-bugs)]

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.

[Thomas (thomas-redhat-bugs)]

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

[Fedora (fedora-redhat-bugs)]

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

[Matthias (matthias-redhat-bugs)]

Thanks a log David and Thomas, it works with NetworkManager-1.2.4-3.fc24 !

[Fedora (fedora-redhat-bugs)]

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.

[Dennis (dhemker)]

Affects me in Ubuntu 16.04 Mate as well. Also experiencing some disconnects

[M.Eng. René Schwarz (dignative)]

I am experiencing the same kind of issue with a vanilla Ubuntu 16.04.1 LTS installation with openconnect 7.06-2build2 and network-manager-openconnect 1.2.0-0ubuntu0.16.04.1.

[dwmw2 (dwmw2)]

This is actually a NetworkManager bug. As noted in bug 1648905 it's fixed upstream by https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-2&id=bb45adeda0bf427ada23b09daf970b0757e82d60

[Launchpad Janitor (janitor)]

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

[Kostadin Stoilov (kmstoilov)]

This together with #1575354 make openconnect barely usable on Ubuntu 16.04. You have to be super quick to enter your credentials before it times out. If either of them would be solved it would at least make it tolerable.

[David Hrbáč (davidhrbac)]

It has been resolved in upstream in NetworkManager-1.2.4-3.fc24 on 2016-10-14 22:49:53 EDT. See https://bugzilla.redhat.com/show_bug.cgi?id=1332491

Can you provide the update for Ubuntu?

[Robin Friberg (robin-friberg)]

I'm also running into this bug and would like to see the fixed code reach Ubuntu 16.10.
I was previously running Debian testing (Stretch) where I had the problem for a long time, but it eventually got patched.

[Tomas Angelo (tommyangelo)]

On Ubuntu 16.04 LTS I solved this by installing the latest package from zesty

http://packages.ubuntu.com/search?keywords=network-manager&searchon=names&suite=all&section=all

http://packages.ubuntu.com/zesty/amd64/network-manager/download

sudo synaptic
Settings -> Repositories

Tab Other Software
Click on Add
deb http://sk.archive.ubuntu.com/ubuntu zesty main

Now refresh packages and type network-manager to search, select (only) that package and press CTRL+E (for choosing version of package) and select latest from zesty.

NOTICE: After upgrading network-manager package I recommend to disable this repository, because probably you do not want to mixture your system with various different packages that can affect stability of your system.

[Christopher Bunn (chalbu)]

On Xubuntu 16.04 LTS, the solution described by tommyangelo resolved the issue.
Thank you Tomas.

[Mike Miller (mtmiller)]

Since it has been confirmed that this is fixed in the latest development release (or by installing the network-manager package pulled from the latest release), someone affected by this bug might want to look at contributing a Stable Release Update for 16.04.

https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

[David Hrbáč (davidhrbac)]

Seems to be working on 16.04.2 now.

[Frédéric Courchesne (courchef)]

Yep! working on ubuntu 16.04.2 now.

[Carl Ponder (cponder)]

I was having the same problem, and updating to 16.04.2 was the solution for me, specifically

    sudo apt-get -y dist-upgrade

given that I was already running 16.04. The problem had also been reported here

    https://askubuntu.com/questions/835556/network-manager-doesnt-remember-login-username/913179?noredirect=1#comment1438576_913179

and solved the same way.
I'd suggest that this bug be considered closed.

[Sebastien Bacher (seb128)]

Thanks, closing the bug then

[GeekSmith (lixo-geeksmith)]

This bug resurfaced in Ubuntu 19.04 and persists in 19.10. I installed a fresh copy of both, installed network-manager-openconnect and network-manager-openconnect-gnome, and connected to the company VPN. The password is saved but the username is not saved and it must be manually entered.

I didn't see this issue in 18.10.

[Mark Duncan (eattheapple)]

I can confirm, this bug is back. The password is saved, but the username is not.

[UnSandpiper (aybora)]

Also happens again in Fedora 30.
It was still working in Fedora 29.

[dwmw2 (dwmw2-redhat-bugs)]

According to https://bugs.launchpad.net/bugs/1609700 this bug has reoccurred in f30.

[dwmw2 (dwmw2-redhat-bugs)]

*** Bug 1705711 has been marked as a duplicate of this bug. ***

[dwmw2 (dwmw2-redhat-bugs)]

I wonder if this regression is caused by https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=009f7560867e939 ?

[dwmw2 (dwmw2-redhat-bugs)]

Please test the Fedora 30 build with that commit reverted, at https://koji.fedoraproject.org/koji/taskinfo?taskID=36857342

[dwmw2 (dwmw2-redhat-bugs)]

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.

[compubear (compubear-redhat-bugs)]

Just wanted to mention that this 'bug/issue' is also present in the current Fedora 31 beta with the following packages:

NetworkManager-openconnect-gnome-1.2.6-2.fc31.x86_64
NetworkManager-openconnect-1.2.6-2.fc31.x86_64
NetworkManager-1.20.4-1.fc31.x86_64

[datakid (datakid)]

I can also confirm on Ubuntu 19.10 with network-manager 1.20.4-2ubuntu2 and openconnect 8.02-1build1 amd64

[Ilario Sanseverino (ippattume)]

I too confirm the bug in Ubuntu 19.10

network-manager 1.1.20.4-2ubuntu2 amd6420.4-2ubuntu2 amd64
network-manager-openconnect 1.2.4-2ubuntu1 amd64
openconnect 8.02-1build1 amd64

[Jakub (buri)]

Also happening on OpenSUSE Tumbleweed 20191101

[champetier.etienne (champetier.etienne-redhat-bugs)]

This is happening to me with F31 and some Anyconnect VPNs

NetworkManager-openconnect-gnome-1.2.6-2.fc31.x86_64
NetworkManager-openconnect-1.2.6-2.fc31.x86_64
NetworkManager-1.20.6-1.fc31.x86_64

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

[udayreddy (udayreddy-redhat-bugs)]

This is happening to me with F30 with the latest updates as of date.

NetworkManager-openconnect-1.2.6-2.fc30.x86_64

[Jerome Covington (jeromecovington)]

Confirmed this bug is an issue for me in Ubuntu 19.10 as well.

Package: network-manager-openconnect
Architecture: amd64
Version: 1.2.4-2ubuntu1

Package: network-manager-openconnect-gnome
Version: 1.2.4-2ubuntu1

However perhaps network-manager-openconnect-gnome is deprecated?

[GeekSmith (lixo-geeksmith)]

Not deprecated unless it happened very quietly.

[UnSandpiper (aybora)]

Still happening in Fedora 31

NetworkManager-openconnect-1.2.6-2.fc31.x86_64

[Jerome Covington (jeromecovington)]

I can also confirm that on another laptop that I upgraded from Ubuntu 18.04 -> 18.10 -> 19.04 -> 19.10 with the following versions that the username was stored (at some point) successfully, and I do not need to enter it when joining the vpn.

network-manager-openconnect:
  Installed: 1.2.4-2ubuntu

network-manager-openconnect:
  Installed: 1.2.4-2ubuntu

Note these are same versions as installed on the laptop that has the bug. That laptop was never upgraded but had Ubuntu 19.10 installed fresh prior to installing the nm packages.

[pureblood (freeseek)]

I can also confirm the same bug is present in Ubuntu 19.10 with package network-manager 1.20.4-2ubuntu2.

[Filipe Silva (filipe-silva)]

Happening here too in a fresh install of Ubuntu 19.10.

[GeekSmith (lixo-geeksmith)]

This bug was reported to have resurfaced exactly 5 months ago, confirmed by several other community members here. When will the status be updated to reflect this and the bug be put on track for resolution?

[Yannis Tsop (ogiannhs)]

Please reopen the bug!

[Sebastien Bacher (seb128)]

Don't comment on a close bug, if that's still a problem better to report a new bug (using ubuntu-bug so the system informations are included)

[GeekSmith (lixo-geeksmith)]

Sebastien Bacher - please see https://bugs.launchpad.net/ubuntu/+source/network-manager-openconnect/+bug/1838838

[GeekSmith (lixo-geeksmith)]

If you are affected by this bug, please comment on the bug above. It has been open since August 2019.

[thaller (thaller-redhat-bugs)]

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.

[dwmw2 (dwmw2-redhat-bugs)]

Now https://gitlab.gnome.org/GNOME/gnome-shell/issues/2105