Unfortunately teamd doesn't have an asynchronous way to notify a
change in the actual configuration, so when a port is enslaved or
released we wait some time for the changes to take effect and read the
configuration again.
https://bugzilla.redhat.com/show_bug.cgi?id=1310435
Request the actual configuration when reading it from teamd. The
actual configuration, differently from the normal one, doesn't contain
non-active team ports.
Virtual devices don't have a valid permanent hw address: when activating
a connection against a specific interface, a check is performed on the
device MAC address too: if it is an empty string, give a try to the
currently assigned MAC address.
enables (back) matching against 802-3-ethernet.mac-address and
802-3-ethenet.mac-address-blacklist connection parameters
for MAC addresses belonging to virtual devices too.
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
