Future patches will create devices long before they are backed by
kernel resources, so we need to split NMDevice object creation from
actual setup based on the backing resources.
This patch combines the NMDeviceFactory's new_link() and
create_virtual_device_for_connection() class methods into a single
create_device() method that simply creates an unrealized NMDevice
object; this method is not expected to fail unless the device is
supposed to be ignored. This also means that the NMDevice
'platform-device' property is removed, because a platform link
object may not be available at NMDevice object creation time.
After the device is created, it is then "realized" at some later
time from a platform link (for existing/hardware devices via the
realize() method) or from an NMConnection (for newly created software
devices via the create_and_realize() NMDeviceClass methods).
https://bugzilla.gnome.org/show_bug.cgi?id=737458
Configuration commit is an unsafe thing to do for assumed connections,
it can remove an externally added address we don't know about yet.
The device already has a link-local address; for an assumed connection
it's the reason we assumed the method=link-local in the first place.
Make all mac-address properties (including NMSettingBluetooth:bdaddr,
NMSettingOlpcMesh:dhcp-anycast-addr, and NMSettingWireless:bssid) be
strings, using _nm_setting_class_transform_property() to handle
translating to/from binary form when dealing with D-Bus.
Update everything accordingly for the change, and also add a test for
transformed setting properties to test-general.
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
We want to set the WWAN config last, to ensure that the configuration we
use overwrites anything that pppd might have set, becuase it touches some
stuff itself. That means we have to keep the WWAN config separate, since
dev_ip4_config is used for DHCP and IPv4LL, which we always set first to
ensure they these don't overwrite external, administrator added config
(eg, priv->ext_ip4_config).
This also synchronizes the IPv4 config path with the upcoming IPv6
config path.
The IP interface may have its own hardware address (like the net
port for WWAN devices) and that's the hardware address that must be
used for DHCP and IPv6 SLAAC, not the hardware address (if any) of
the NMDevice itself.
This patch does change the NMDevice hardware address property to
always be the Device's hardware address, instead of the IP interface
hardware address. This means that ADSL and WWAN will no longer
change their hardware address to the hardware address of their
IP interface. But in all these cases, the hardware address is
non-existent (PPP) or transient and meaningless (WWAN/ADSL).
If the initial attempt to assume a connection on a device fails, and
the device remains un-activated, but then something changes its
configuration externally, try to generate a new connection and assume
that.
Add a generic signal that devices can use to indicate that something
material in the network situation changed, and that auto-activation
may now be possible. This reduces specific knowledge of device types
in the policy.
In reality the connection provider (NMSettings) is always the same
object, and some device plugins need access to it. Instead of
cluttering up the device plugin API by passing the provider into
every plugin regardless of whether the plugin needs it, create
a getter function.
Use the new kernel physical_port_id interface property to recognize
when two devices are just virtual devices sharing the same physical
port, and refuse to bond/team multiple slaves on the same port.
Rather than passing UDI, ifname, and driver name to the device
constructors as separate arguments, just pass the NMPlatformLink
instead and let it parse them out.
Virtual types still take UDI and ifname separately, since we create
fake NMDevices for them for autoactivating connections. That's weird
in other ways too though, so perhaps this should be revisted.
This is really, really old 2007-era code. Any NMDevice that gets
created is already supported, so there's no reason to have every
device set NM_DEVICE_CAP_NM_SUPPORTED. For those subclasses that
only set that capability, we can remove the subclass method
entirely. Next, it turns out that the "type capabilities" code
wasn't used anywhere, so remove that too. Lastly, "cipsec"
interfaces haven't been used on linux in about 5 years (they
were created by the Cisco binary-only IPSec kernel module for
Cisco VPNs long before vpnc and openswan came around) so we can
remove that code too.
