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
When the master connection deactivates, we also fail slave
connections; but if the master deactivation happens just before a
slave reaches the PREPARE state, we failed to notice it and keep
the slave stuck without chance of progressing. Fix this.
Since nm_device_slave_notify_release() is called from outside the
activation chain of the slave device (it gets called from the master
device) there might be pending activation sources scheduled, clear
them before queueing a state change.
In case, where both
%global snapshot git20160606
%global git_sha b769b4df
is set, they version number should be
.git20160606.b769b4df
not
.b769b4df.git20160606
Previously we used defines for bond option names and used string
literals for their attribute names in sysfs. But they are the same by
definition so let's use defines also for attributes.
Even if the 'ad_actor_system' option is only valid for the 802.3ad
mode, the sysfs file is always present and has a default value of
''. But in 802.3ad mode the default value is
'00:00:00:00:00:00'. Return the correct value in
nm_setting_bond_get_option_default().
Furthermore, writing a empty string to the file will generate an
error, don't do it.
We print an error when the write of a bond options fails as this is
considered an effect of a wrong configuration (or a bug in the checks
done by NM) that the user should notice. But not all options are
supported in all bonding modes and so we ignore some unsupported
options for the current mode to avoid populating logs with useless
errors.
Improve the code there by using a more generic approach and
synchronize the mode/option compatibility table with kernel (file
drivers/net/bonding/bond_options.c).
https://bugzilla.gnome.org/show_bug.cgi?id=767776https://bugzilla.redhat.com/show_bug.cgi?id=1352131
