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
is_available() appears not to have been updated when supplicant
interface states were consolidated between the manager and the
interface objects long ago. Soon after that, the supplicant
itself added some states.
The wifi device is available to activate whenever the supplicant
is READY or in one of it's operational modes, ie up until
COMPLETED. Any other state means the supplicant is not ready.
It contains logging domains that are active by default. It allows users
to set default domains back easily (after they changed them).
And fix formatting of "} else if".
Since the manager now tracks active connections, it needs to hold
a reference to the active connection objects too. The active
connection teardown code was changed to release that reference
(_active_connection_cleanup()) but the creation code was never
changed to remove the bits that pass ownership over the initial
reference to the NMDevice. Fix that.
No need to copy the list when (a) we never care if it gets modified
in-place (since the loops break when the connection is found) and
(b) we never modify it in place anyway. Reduces the possibility of
leaking the list due to programming errors too.
Will replace the VPN manager's activated/deactivated signals; listeners
can attach to the active connection's 'state' property and listen
for the changes to ACTIVATED and DEACTIVATED. Works for all connections,
not just VPN ones.
Instead of using devices as a proxy for active connections, and
then also asking the VPN manager for the active connections it's
tracking, just track *all* active connections in the manager.
We'll want to use NMActiveConnection more in the manager and also fold
the PendingActivation functionality into it. All this functionality
applies to the VPN connections too, so it makes sense to have it all
in the base class instead of both NMActRequest and NMVPNConnection.
