This fixes a glib assertion.
Backtrace:
#0 0x00007f139ab08e0d in g_logv () from /lib64/libglib-2.0.so.0
#1 0x00007f139ab08ff2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x0000003f9aa3151a in g_type_check_instance () from /lib64/libgobject-2.0.so.0
#3 0x0000003f9aa272d4 in g_signal_handlers_disconnect_matched () from /lib64/libgobject-2.0.so.0
#4 0x0000000000495b7d in supplicant_interface_release (self=0xc58040) at devices/nm-device-wifi.c:423
#5 0x0000000000498a28 in dispose (object=0xc58040) at devices/nm-device-wifi.c:3525
#6 0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
#7 0x000000000047699a in remove_device (manager=manager@entry=0xc09050, device=0xc58040, quitting=quitting@entry=1) at nm-manager.c:748
#8 0x0000000000478a84 in dispose (object=0xc09050) at nm-manager.c:4558
#9 0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
#10 0x0000000000428cc0 in main (argc=1, argv=0x7fffc0948c98) at main.c:626
Signed-off-by: Thomas Haller <thaller@redhat.com>
libgsystem contains more than just the local allocation macros; in the
future we will likely want to make use of some of this such as the
structured logging support.
These devices don't have a platform device at creation time, thus
is_software wasn't getting set properly. Move the is_software
decision to constructed() because by this point, the iface and
ifindex (if present) will be known for all cases and thus we can
figure out if it's a software device or not in one place.
This backwards compatible patch adds the possibility to use new
nm_device_generate_connection() API via update_connection() virtual
method implementations in NMDevice subclasses.
Compatibility is achieved by first trying to use the older API and
match_l2_config() virtual method and only then moving on to
update_connection().
The nm_device_generate_connection() calls update_connection() to create
type-specific NMSetting instances and verifies the connection before
returning it. To avoid tinkering with NMSettingConnection in
update_connection() we use a class attribute called connection_type
which is used by nm_device_generate_connection() itself.
Known issues:
* nm_device_generate_connection() method doesn't implement DHCP lease
configuration matching. We shouldn't actually need it but if a use case
for that will come out, we can fix it later.
* nm_device_generate_connection() doesn't fill in the slave-specific
options.
* update_connection() is not implemented and connection_type is not set
in the subclasses. This will be fixed in individual patches.
* NMSetting's compare_property() implementations in combination with
NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering
false negatives in some cases. Same as above.
Acked-by: Dan Winship <danw@gnome.org>
Acked-by: Thomas Haller <thaller@redhat.com>
Whether an active connection is assumed or connected from scratch is
only important during nm_device_activate(). When the activation process
is set up, there's no difference from any other active connection.
Acked-by: Dan Winship <danw@gnome.org>
Acked-by: Thomas Haller <thaller@redhat.com>
The link_changed method expects a valid info parameter.
NMDeviceMacvlan and NMDeviceGre calls link_changed
during construction for initialization.
As it was before, NMDeviceMacvlan and NMDeviceGre passed
NULL as NMPlatformLink, causing NM to segfault.
(Regression was introduced in 0e361e894c)
https://bugzilla.redhat.com/show_bug.cgi?id=997396
Signed-off-by: Thomas Haller <thaller@redhat.com>
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
Add a property on NMManager indicating that it is currently starting
up and activating startup-time/boot-time network connections.
"startup" is initially TRUE, and becomes FALSE once all NMDevices
report that they have no pending activity (eg, trying to activate,
waiting for a wifi scan to complete, etc). This is tracked via a new
NMDevice:has-pending-activity property, which is maintained partially
by the device itself, and partially by other parts of the code.
Software devices don't have a UDI until udev finds them, and since we need
to know about the software devices before udev finds them the UDI will be
missing. Instead of requiring a UDI on NMDevice creation, update the
property from the NMPlatform link change signal when udev does find the
device.
Now that a UDI is no longer required for device creation, software devices
added by NM would be created in the platform_link_added_cb() signal
handler triggered by the various software device creation methods in
system_create_virtual_device() (eg nm_platform_bridge_add() etc). Then
the NMDevice created in system_create_virtual_device() would be a duplicate
and cause problems when it was added. Since system_create_virtual_device()
needs to do setup on some devices, suppress the device creation from the
platform link added handler in this function.
Much of this is a hack which should be cleaned up later.
The unref in finalize is not needed, because the hash table gets already freed
in dispose.
Note that setting available_connections to NULL in dispose is not really
needed, because (altough dispose might be called more than once) there
is a guarded by "priv->disposed = TRUE;". But leave it for clearity in
case somebody tries to access the pointer (which shouldn't happen).
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a device is removed, then trying to reset its IPv6 state will cause
nm_utils_do_sysctl() to log a warning since the path no longer exists.
So don't try to do it in that case.
The switch to combine IPv4 configs to arrive at the final config would
cause externally added addresses and routes to be removed from the
interface when a DHCP or LLv4 event came in, becasue the externally
added details weren't cached anywhere and thus would be dropped on the
IP changes.
When a VPN wanted to add some routes (like the host route for the
VPN gateway) it would add them itself and listen for parent device
events and re-add them if necessary. That's pretty fragile, plus
the platform blows away routes that aren't part of the IP config
that's getting applied.
So we might as well just have the VPN connection tell the parent
what the routes are, and have the parent device handle updating
the routing. The routes are through the parent device anyway,
and so are "owned" by the parent too.
Like IPv6, keep the DHCP/LLv4 config separate and combine it with the
NMSettingIP4Config to arrive at the final, combined IP4 config. This
brings the behavior in line with IPv6 code flow and will allow adding
the VPN routes config into the mix more easily.
It appears the kernel does not send notifications via netlink if the
default route is removed in some cases. This causes the platform
route cache to become stale, and thus when the default route is
reset by NM the platform thinks the route already exists, and does
not add it. But the route doesn't exist, becuase the kernel silently
removed it without telling anyone.
Fix that with a big hammer by flushing/refilling the route cache when
devices are deactivated (deletion of their addresses causes the default
route to be removed by the kernel) and when the default route is
updated by NM itself.
Pavel: if we find a more granular method, we should probably revert
this as the cache refill can be expensive.
Bluetooth device hardware addresses won't change during the lifetime
of the object (since that would mean a completely new device) and
they also won't have an ifindex because they aren't netdevices.
Various bits of the core periodically call nm_device_update_hw_address()
to update a device's hardware address, but this function expects that
any device with a hardware address also has an ifindex. Except that
Bluetooth devices don't because they aren't netdevices.
Modify the get_hw_address_length() function to return a boolean
indicating whether or not the address can ever change, and set that
for BT devices. nm_device_update_hw_address() then exits early if
there's no point in re-checking the hardware address, avoiding the
assertion.
https://bugzilla.gnome.org/show_bug.cgi?id=701744
The previous ignore-carrier rules did not work well with dynamic IP
(dhcp/slaac) connections. Change the rule so that only static IP
connections can be activated when carrier is not present (but both
static and dynamic connections will remain up when carrier is lost).
Callers of these functions now only care whether two IP configs are
different and not what specific property changed, so we can simplify
this code down to a simple comparison for equality, based on the hashing
that's already done for the DNS manager.
