Unrealized devices aren't backed by kernel resources and so won't know
all of their attributes. That means three things:
1) they must update their attributes when they become realized
2) they must clear those attributes when unrealized
3) they must be looser in checking compatible connections until
they are realized
This requires that the setup() function be split into two parts, start & finish,
because finish must be run after add_device()
Also, we can simplify whether to pay attention to 'recheck-assume', which
is now dependent on priv->is_nm_owned, because the only case where NM should
*not* listen for the 'recheck-assume' signal is when the device is a
software device created by NM itself. That logic was previously spread
across the callers of add_device() but is now consolidated into
nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
Clone the connection upon activation. This makes it safe for the user
to modify the original connection while it is activated.
This involves several changes:
- NMActiveConnection gets @settings_connection and @applied_connection.
To support add-and-activate, we constructing a NMActiveConnection with
no connection set. Previously, we would set the "connection" field to
a temporary NMConnection. Now NMManager piggybacks this temporary
connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE).
- get rid of the functions nm_active_connection_get_connection_type()
and nm_active_connection_get_connection_uuid(). From their names
it is unclear whether this returns the settings or applied connection.
The (few) callers should figure that out themselves.
- rename nm_active_connection_get_id() to
nm_active_connection_get_settings_connection_id(). This function
is only used internally for logging.
- dispatcher calls now get two connections as well. The
applied-connection is used for the connection data, while
the settings-connection is used for the connection path.
- needs special handling for properties that apply immediately
when changed (nm_device_reapply_settings_immediately()).
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=724041
It might just be that we didn't see it yet; either on daemon startup on in a
race. The nm_platform_*_add() deals with the device already being there in
_link_add_check_existing().
NetworkManager:ERROR:devices/nm-device-bridge.c:402:create_and_realize: assertion failed: (nm_device_get_ifindex (device) <= 0)
Program received signal SIGABRT, Aborted.
0x00007ffff46965d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Missing separate debuginfos, use: debuginfo-install bluez-libs-5.23-4.el7.x86_64
(gdb) bt
#0 0x00007ffff46965d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff4697cc8 in __GI_abort () at abort.c:90
#2 0x00007ffff4a916d5 in g_assertion_message (domain=domain@entry=0x5a5088 "NetworkManager", file=file@entry=0x59b0f2 "devices/nm-device-bridge.c", line=line@entry=402, func=func@entry=0x59b3f0 <__FUNCTION__.29169> "create_and_realize", message=message@entry=0xa76a30 "assertion failed: (nm_device_get_ifindex (device) <= 0)") at gtestutils.c:2292
#3 0x00007ffff4a9176a in g_assertion_message_expr (domain=domain@entry=0x5a5088 "NetworkManager", file=file@entry=0x59b0f2 "devices/nm-device-bridge.c", line=line@entry=402, func=func@entry=0x59b3f0 <__FUNCTION__.29169> "create_and_realize", expr=expr@entry=0x59aef8 "nm_device_get_ifindex (device) <= 0") at gtestutils.c:2307
#4 0x0000000000447cb6 in create_and_realize (device=0xa77f40 [NMDeviceBridge], connection=0x8d0200, parent=<optimized out>, out_plink=0x7fffffffd700, error=0x0) at devices/nm-device-bridge.c:402
#5 0x000000000045d560 in nm_device_create_and_realize (self=self@entry=0xa77f40 [NMDeviceBridge], connection=connection@entry=0x8d0200, parent=<optimized out>, error=error@entry=0x0)
at devices/nm-device.c:1594
#6 0x00000000004d4b64 in system_create_virtual_device (self=self@entry=0x8802b0 [NMManager], connection=connection@entry=0x8d0200, error=error@entry=0x0) at nm-manager.c:983
#7 0x00000000004d4d71 in system_create_virtual_devices (self=0x8802b0 [NMManager]) at nm-manager.c:1022
#8 0x00000000004d47a5 in add_device (self=<optimized out>, device=<optimized out>, try_assume=<optimized out>) at nm-manager.c:1785
#9 0x00000000004d501f in platform_link_added (self=self@entry=0x8802b0 [NMManager], ifindex=<optimized out>, plink=plink@entry=0xa7f810) at nm-manager.c:1887
#10 0x00000000004d7c24 in nm_manager_start (self=0x8802b0 [NMManager]) at nm-manager.c:1959
#11 0x00000000004d7c24 in nm_manager_start (self=self@entry=0x8802b0 [NMManager], error=error@entry=0x7fffffffd930) at nm-manager.c:4178
#12 0x00000000004459ec in main (argc=1, argv=0x7fffffffda88) at main.c:442
(gdb)
The localization headers are now included via "nm-default.h".
Also fixes several places, where we wrongly included <glib/gi18n-lib.h>
instead of <glib/gi18n.h>. For example under "clients/" directory.
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
Move D-Bus export/unexport handling into NMExportedObject and remove
type-specific export/get_path methods (export paths are now specified
at the class level, and NMExportedObject handles the counters for all
exported types automatically).
Since all exportable objects now use the same get_path() method, we
can also add some helper methods to simplify get_property()
implementations for object-path and object-path-array properties.
Add NMExportedObject, make it the base class of all D-Bus-exported
types, and move the nm-properties-changed-signal logic into it. (Also,
make NMSettings use the same properties-changed code as everything
else, which it was not previously doing, presumably for historical
reasons).
(This is mostly just shuffling code around at this point, but
NMExportedObject will be more important in the gdbus port, since
gdbus-codegen doesn't do a very good job of supporting objects that
export multiple interfaces [as each NMDevice subclass does, for
example], so we will need more glue/helper code in NMExportedObject
then.)
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Later remove nm_platform_get_error() and signal errors via return
error codes.
Also, fix nm_platform_infiniband_partition_add() and
nm_platform_vlan_add() to check the type of the existing link
and fail with WRONG_TYPE otherwise.
We need to know whether we can create interfaces of any given
NMDevice subclass or not. So don't rely on just the NMPlatformLink
for that information, because we won't have a platform link for
software devices before we create them.
Instead of hacky stuff in the Manager, let plugins themselves indicate
which links should be ignored (because they are really child links that
are controlled by a different device that the plugin handles).
Instead of looping over all plugins and asking each plugin whether it
can handle a link or a connection, have them advertise the link and
connection types they support, and use that when creating new devices.
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
The merge of lr/udev-unmanaged-fd731014 made all devices wait until
udev found them, but that makes these three device types fail activate
when created by NM itself.
Since their availability depended on IFF_UP, they could not be
activated (eg, 'nmcli con up team0') until they were IFF_UP. But
when they are created by NM, although NM knows the ifindex the
platform ignores the interface until udev finds it. Thus immediately
after creating the interface in _internal_activate_device() it
won't be known to the platform, so the nm_device_is_available()
check that controls whether the device moves to DISCONNECTED
will fail. This prevents any activation and emits the message:
"Connection 'foo' is not available on the device %s at this time."
because the device is still in the UNAVAILABLE state.
danw asked why we care about IFF_UP for these devices, and I can't
remember why, and I don't think it makes sense to require now.
https://bugzilla.gnome.org/show_bug.cgi?id=746918
Add nm-core-types.h, typedefing all of the GObject types in
libnm-core; this is needed so that nm-setting.h can reference
NMConnection in addition to nm-connection.h referencing NMSetting.
Removing the cross-includes from the various headers causes lots of
fallout elsewhere. (In particular, nm-utils.h used to include
nm-connection.h, which included every setting header, so any file that
included nm-utils.h automatically got most of the rest of libnm-core
without needing to pay attention to specifics.) Fix this up by
including nm-core-internal.h from those files that are now missing
includes.
Most NMDevice types defined their own error domain but then never used
it. A few did use their errors, but some of those errors are redundant
with NMDeviceError, and others can be added to it.
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.
NMDeviceBond, NMDeviceBridge, and NMDeviceTeam all used basically the
same code to generate a default interface name. Move it into
nm_utils_complete_generic().
The virtual :interface-name properties (eg,
NMDeviceBond:interface-name) are deprecated in favor of
NMSettingConnection:interface-name, and nm_connection_verify() ensures
that their values are kept in sync. So (a) there is no need to set
those properties when we can just set
NMSettingConnection:interface-name instead, and (b) we can replace any
calls to the setting-specific get_interface_name() methods with
nm_connection_get_interface_name() or
nm_setting_connection_get_interface_name().
Since we enforce the fact that bond, bridge, team, and vlan
interface-name properties match NMSettingConnection:interface-name,
nm_connection_get_virtual_iface_name() can be replaced with
nm_connection_get_interface_name() basically everywhere.
The one place this doesn't work is with InfiniBand partitions (where
get_virtual_iface_name() was actually computing the name), but for the
most part we only need to care about the interface names of InfiniBand
partitions in places where we also already need to do some other
InfiniBand-specific handling as well, so we can use an
InfiniBand-specific method
(nm_setting_infiniband_get_virtual_interface_name()) to get it.
(Also, while updating nm_device_get_virtual_device_description(), fix
it to handle InfiniBand partitions too.)
For NMDeviceWifi and NMDeviceWimax, the printf format string for
nm_utils_complete_generic() was created based on ssid/nsp. Since
these input strings are untrusted, this is a serious bug.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Now that we have nm_utils_hwaddr_matches() for comparing addresses
(even when one is a string and the other binary), there are now places
where it's more convenient to store hardware addresses as strings
rather than binary, since we want them in string form for most
non-comparison purposes. So update for that.
In particular, this also changes nm_device_get_hw_address() to return
a string.
Also, simplify the update_permanent_hw_address() implementations by
assuming that they will only be called once. (Since they will.)
Add nm_utils_hwaddr_matches(), for comparing hardware addresses for
equality, allowing either binary or ASCII hardware addresses to be
passed, and handling the special rules for InfiniBand hardware
addresses automatically. Update code to use it.
Include <linux/if_ether.h> and <linux/if_infiniband.h> from
nm-utils.h, to get ETH_ALEN and INFINIBAND_ALEN, and remove those
includes (as well as <net/ethernet.h> and <netinet/ether.h>, and
various headers that had been included to get the ARPHRD_* constants)
from other files where they're not needed now.
Remove all remaining GParamSpec name and blurb strings (and fix
indentation while we're there), and add G_PARAM_STATIC_STRINGS to all
paramspecs that were lacking it.
If a link's "master" property changes unexpectedly (ie, from outside
NM), update the master and slave NMDevices to reflect it, without
making any changes to them.
This feature requires recent support from the kernel.
Most notably these upstream kernel commits are required:
- 92c0574f11598c8036f81e27d2e8bdd6eed7d76d
- 43598813386f6205edf3c21f1fe97f731ccb4f15
- 30313a3d5794472c3548d7288e306a5492030370
The latter of them was merged to upstream kernel version 3.15-rc5.
https://bugzilla.gnome.org/show_bug.cgi?id=729844
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add an additional address parameter to link_add/bridge_add, to set the
MAC address of software devices.
https://bugzilla.gnome.org/show_bug.cgi?id=729844
Signed-off-by: Thomas Haller <thaller@redhat.com>
Assumed slave connections need to be added to their master devices,
which didn't used to happen because the devices activating assumed
connections jumped directly to stage3, bypassing all the master/slave
handling stuff.
Instead, make all assumed connections go through all activation stages,
but make sure that things which touch the device don't get done for
assumed connections. This requires moving the master/slave code out
of the override-able class methods because we need to call the
master/slave code for assumed connections, but we don't want to call
the override-able class activation methods.
Master devices depend on their slaves/ports for carrier status, so the
carrier can't factor into whether a connection is available on that
device or not. If it did, then no connections could be activated
because the device doesn't have a carrier until slaves are attached.
