The bridge master's carrier follows IFF_UP when no ports are added
and the ports' carrier when ports are added, so we shouldn't
depend on carrier when deciding whether to activate a bridge which
may not have any ports. Also when the
Bond master carrier state follows slave carriers, so clearly we
can't depend on carrier when deciding whether we can activate a
bond connection which doesn't yet have any slaves. Also, when
the bond's carrier goes down, we don't want to deactivate the
connection because this is normal in some failover modes and
could be the user reconfiguring slaves.
Less confusing in the logs to see the change logged before listeners
have a chance to emit other log messages that may depend on the new
carrier state.
The kernel bonding code calls "closes" (which clears IFF_UP) the slave
and restores some of its attributes (MAC address, MTU, etc), but doesn't
bring it back up. This breaks things like carrier detection, and
indeed when the device is closed, its carrier is also cleared, which
leads us to think the device is not available for activation.
To ensure that further events are noticed by the device, and that its
carrier state is accurately represented, make sure the device is still
IFF_UP after it has been released.
The hardware address of a device often changes when slaves change,
for example with bond interfaces, which take the hardware address of
their first slave. Make sure that's always up-to-date.
It's not very helpful to deactivate a slave of a bond or a bridge
port because the carrier is lost. Carrier failures are normal
operation when using various bonding failover modes. For bridge
ports, it's probably not very helpful either. Given that the
masters are all virtual interfaces and have been explicitly
configured and started by a user, the configuration should
generally be left alone unless explicitly deactivated or changed.
Two things:
1) When the slave was deactivated, nm_device_deactivate() runs before
the master gets the slave's state-changed signal, and thus priv->master
is cleared long before nm_device_notify_enslaved() is called. Which
would trigger the g_assert (priv->master).
2) If the slave is already deactivated, there's no point in re-queueing
a state change to deactivated.
So just assert that priv->master is valid if the slave is going to be
enslaved, but if the slave is being released, ignore NULL priv->master
which we don't use anyway. Also ignore redundant state changes.
The DUID is supposed to be machine-wide, so if we're writing a new
leasefile, save the default DUID to it. If we haven't saved a
persistent DUID yet, do that to.
Add infrastructure for generating DUID-LLT from a given device MAC and
passing it around to the DHCP client implementations.
Thanks to Mathieu Trudel-Lapierre for bug fixes in the
unescaping code, which were merged into this commit.
Broken by e7caad20c9.
Admittedly, GObject is opaque in this area. But here's the
equivalent concepts in C++:
*_GET_CLASS (object)->function(object):
- call youngest implementation of virtual function; checks current
object for implementation and calls it, if not overridden by the
child, walks up the inheritance chain and calls parent,
grandparent, etc. C++ equivalent is calling foo::function().
*_CLASS (object_parent_class)->function(object):
- call named parent class implementation, *not* including current
object. C++ equivalent is calling ParentClass::function().
Using _GET_CLASS()->function() inside the child implementation of
function() recursively calls the child implementation of function()
and overflows the call stack.
The code flow is actually somewhat simpler this way since the
subclasses don't have to ask NMDeviceWired for the address
every time. Plus then NMDeviceWired doesn't have to know
anything about its subclasses in the constructor.
Instead of using a mix of netlink and SIOCGIFHWADDR and doing it
in every device, create a utility function for this and have
everywhere else call that.
Modern operating systems come with systemwide "crash catching"
facilities; for example, the Linux kernel can now pipe core dumps out
to userspace, and programs like "systemd-coredump" and "abrt" record
these.
In this model, it's actively counterproductive for individual
processes to catch SIGSEGV because:
1) Trying to unwind from inside the process after arbitrary
corruption is destined to fail.
2) It hides the fact that a crash happened at all - my OS test
framework wants to know if any process crashed, and I don't
want to guess by running regexps against /var/log/Xorg.0.log
or whatever.
Signed-off-by: Colin Walters <walters@verbum.org>
https://bugzilla.gnome.org/show_bug.cgi?id=692032
