Now that NMDevice reads the hwaddr directly from netlink, it's silly
to have every device subtype maintain its own hw-address property
(using data that it gets from the NMDevice base class).
Remove all the device-specific hw-address properties, and add one to
NMDevice instead. (Because of the way nm-properties-changed-signal
works, this has no effect on the D-Bus API.) Subclasses now call
nm_device_get_hw_address() in places where they used to just refer to
priv->hw_addr (and to simplify this, we now allow passing NULL for the
out length parameter, since the subclasses almost always know what the
length will be already).
Also reorganize/simplify a few other methods to take advantage of the
fact that NMDevice is now keeping track of the hw-address directly.
https://bugzilla.gnome.org/show_bug.cgi?id=699391
As with the other connection-matching methods, move the loop and the
device-independent bits into NMDevice. By reusing
nm_device_check_connection_compatible(), this means that most device
types now no longer need any type-specific code for this.
https://bugzilla.gnome.org/show_bug.cgi?id=693684
nm_device_connection_match_config() sounded more generic than it
really was; rename it to nm_device_find_assumable_connection(), which
is what it really does.
There was also a lot of redundancy/cut+paste in the subclass
implementations of connection_match_config(); Improve things by moving
the looping-over-connections code into NMDevice itself, and also doing
the general-device-compatibility and IP-config checking there, leaving
the device subclasses to just verify L2 properties. Which most of them
aren't doing...
https://bugzilla.gnome.org/show_bug.cgi?id=693684
Since NMDevice has a generic get_hw_address() method now, it can do
nm_device_spec_match_list() itself (for everything except ethernet,
which needs to match against s390 subchannels too).
https://bugzilla.gnome.org/show_bug.cgi?id=693684
Add a "need_carrier" argument to nm_device_is_available(), to allow
distinguishing between "device is not available", "device is fully
available", and "device is available except for not having carrier".
Adjust various parts of NMDevice and NMManager to allow for the
possibility of activating a connection with :carrier-detect = "no" on
a device with no carrier, and to avoid auto-disconnecting devices with
:carrier-detect = "on-activate".
https://bugzilla.gnome.org/show_bug.cgi?id=688284
Move some duplicated carrier-handling code into NMDevice (which can
introspect itself to see if it's a subclass that has carrier).
The "mostly ignore carrier" special handling for bridges and bonds is
now also handled as part of the NMDevice-level carrier handling.
https://bugzilla.gnome.org/show_bug.cgi?id=688284
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.
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 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.
When no slave is present, dynamic IP configuration (DHCPv4, DHCPv6,
IPv6 autoconf) cannot proceed. But static and link-local
configuration can. So if IPv4 requires DHCP but IPv6 is static,
it makes no sense to block IPv6 configuration from proceeding
just because DHCPv4 cannot.
Rather than having NMDevice subclasses connect to their own
::state-changed signal, fix up the signal definition so they can just
override the class handler.
The idea was copied from gtk, but it's only used there in cases where
the method's wrapper function and default implementation would
otherwise have the same name, which never happens in NM because our
method implementations aren't prefixed with the type name, so it's
just noise here.
There's no way to specify the MAC address bond interfaces have
since they take the MAC address of their slaves, so NMDeviceBond
doesn't implement hwaddr_matches(). This check would always
return FALSE, and thus we'd never match.
