Even when there's no <secret>-flags key for it in vpn-data.
This is essentially to fix regression in the way openconnect uses the VPN
secrets:
Openconnect auth helper is essentially a web browser that fills in an arbitrary
HTML (or XML) form that's used to get the session cookie. The actual secret the
service needs is the cookie itself.
However, what needs to be remembered includes the form data. What data can be
in the form is installation dependent and can not be known in advance. Thus the
flags for it can't be currently set in the connection. The auth helper is not
capable of setting the flags either, because it can only return secrets.
Prior to 1424f249e we treated vpn.secrets without the flags as system secrets
and store them in the connection. Since that commit we just filter them away,
which broke user configurations.
This restores the behavior or treating everyting in vpn.secrets as secrets and
falling back to system secrets.
Another way would be to find a way to flag the secrets, perhaps by
extending the auth helper protocol to be able to store non-secret
properties too.
https://bugzilla.gnome.org/show_bug.cgi?id=768737
On every start of NetworkManager I'd see a warning message:
modem-broadband[cdc-wdm0]: failed to retrieve SIM object: No SIM object available
Apparently, to warn about this is too alarming.
Commit f85941ee91 ("device: don't try to generate ipv6ll address for
disconnected devices") disabled the generation of IPv6 link-local
addresses for disconnected devices to fix a crash. However that broke
the following:
$ ip a f dev eth0
$ systemctl start NetworkManager
$ nmcli d
DEVICE TYPE STATE CONNECTION
eth0 ethernet disconnected eth0
$ ip a a dev eth0 2001::42/64
$ ip a show eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:52:00:61:32:81 brd ff:ff:ff:ff:ff:ff
inet6 2001::42/64 scope global
valid_lft forever preferred_lft forever
(no link-local address)
Instead, enable the generation of a link-local address even if the
device is disconnected and fix nm_device_get_ip_iface_identifier() to
not require a connection if @ignore_token is set.
Fixes: f85941ee91
If the read of teamd configuration failed (possibly due to a timeout),
fail the connection immediately where possible instead of letting it
continue and risk to block again at the next read.
https://bugzilla.redhat.com/show_bug.cgi?id=1257237
When a device is activated any existing teamd instance is killed. But
since commit 28274495d6 ("device/team: always try to connect to
teamd in update_connection()") the disappearing of the D-Bus name
owner always triggers an automatic restart of the instance in
teamd_dbus_vanished() if the name was previously owned. This new
instance conflicts with the instance we're about to start.
Instead, restore the previous behavior of restarting teamd only if
there is an activation in progress and use @tdc as a flag. This also
means that update_connection() should not modify the value of @tdc.
Fixes: 28274495d6
A infinite activation loop can arise when the master repeatedly fails
activating: slave's _internal_activate_device() calls
ensure_master_active_connection() to activate the master connection
and during master activation activate_slave_connections() resets the
retry counter of slaves.
The autoconnect retry counter of a slave should only be reset for
explicit master activations, not for auto-activations.
https://bugzilla.redhat.com/show_bug.cgi?id=1270814
