Since commit 9ff161b2a1 ("device: move have_ip6_address() to
nm_ip6_config_get_address_first_nontentative()") the IP configuration
argument of nm_ip6_config_get_address_first_nontentative() must be
non-NULL. Add checks where needed.
Fixes: 9ff161b2a1
We should not check ip6_config for the link local address because
ip6_config contains the merged settings we want to configure,
not the addresses that are actually configured on the device.
Check ext_ip6_config_captured for that.
Also, reuse nm_ip6_config_get_address_first_nontentative() which
only takes an address after it survived DAD.
It will only be in ext_ip6_config if it was added by the kernel,
which isn't usually the case since NM handles IPv6LL address
generation on new enough kernels.
If the LL address isn't found, IPv6 configuration will never
complete because DHCPv6 was started already but lack of an LL
address bails out early without handling the error.
Fixes: b8c2fc26c1
Calling va_start() (with va_end()) in between seems to work and
is done by systemd and other code occasionally.
However, it's not clear that this really works on every architecture.
So just replace thise one instance with a different implementation
by passing the arguments as an array.
For update, don't delete first and add it again. Just do it
in one step.
For recheck, don't delete all connections first to add them
all anew. Instead, check what changes and only emit the changed
signal if there are any actual changes.
The rules were added to the list using g_slist_append() and then
applied one at time using "iptables --insert" which puts them at the
beginning of the chain, reversing the initial order.
Instead, list them in the desired order and use g_slist_prepend() to
achieve the same result. This has no functional changes.
The function can now be called on unrealized devices before the
initial unmanaged flags are set and for those devices
nm_device_get_managed() will return TRUE. Since we only accept
states > UNMANAGED, return early when the condition is not met.
Fixes the following failed assertion:
carrier_changed: assertion 'priv->state >= NM_DEVICE_STATE_UNAVAILABLE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=760844
The availability checks are called from places that don't assume the device
will be removed mid-air. Call the removal routine only when we're the very
last thing that's being done.
During nm_device_unrealize(), the connection might still
have some connections that only get removed later. We must
garbage collect unrealized devices when they loose their
available-connections, not during unrealize.
Fixes: 436ec5b8e3
Apply MTU and hop limit when managed or other flag is set as well. This wasn't
the case for the first RA and the previous commit made it slightly worse by
always ignoring it.
Fixes: ad2584c375
With DHCPv6 it might be quite some time (we may even time out) until we get all
the information to finish activation, but we already have the addresses and
routes.
With the final removal the reason of NOW_UNMANAGED causes the cleanup on the
device to be run, which downs the device:
#0 nm_platform_link_set_down (self=0x555555a29bb0, ifindex=1711) at platform/nm-platform.c:1111
#1 0x00005555555d6ccf in nm_device_take_down (self=self@entry=0x555555c07c70, block=block@entry=1) at devices/nm-device.c:8175
#2 0x00005555555df0c7 in _set_state_full (self=0x555555c07c70, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_NOW_UNMANAGED, quitting=quitting@entry=0) at devices/nm-device.c:9825
#3 0x00005555555dfa97 in nm_device_state_changed (self=<optimized out>, state=<optimized out>, reason=<optimized out>) at devices/nm-device.c:10084
#4 0x00005555555e472c in nm_device_set_unmanaged_flags (self=<optimized out>, flag=flag@entry=NM_UNMANAGED_INTERNAL, unmanaged=unmanaged@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_UNMANAGED)
at devices/nm-device.c:8745
#5 0x00005555555e54a9 in nm_device_set_unmanaged_quitting (self=<optimized out>) at devices/nm-device.c:8806
#6 0x000055555565b1aa in remove_device (manager=manager@entry=0x555555a4a2c0, device=0x555555c07c70, quitting=quitting@entry=1, allow_unmanage=allow_unmanage@entry=1) at nm-manager.c:833
#7 0x0000555555660b81 in nm_manager_stop (self=0x555555a4a2c0) at nm-manager.c:4389
#8 0x00005555555b3f9b in main (argc=1, argv=0x7fffffffdba8) at main.c:493
The function returns early when autoconnect is off, so there's no reason to
branch for that case below. The signal is only generated for autoconnect=true.
The idea of NMDevice:realize() was to
(1) update the device properties
(2) fail realization if some critical properties are missing
(1) is already done during nm_device_setup_start().
(2) was only implemented by NMDeviceVlan:realize(), but it
basically was just checking whether such a platform device exists.
Other implementations don't do that either and it opens up for a race
when the device gets deleted externally.
All implementations of NMDevice:setup_start() in derived classes
invoke the parent implementation first. Enforce that by moving
NMDevice:setup_start() to realize_start_setup() and only notify
derived classes afterwards via NMDevice:realize_start_notify().
Reapplying a connection should not be done by iterating over and
(unsorted) @diffs array. Instead the order matters! E.g. first layer 2
before IP settings. Thus extracting those individual updates on a per-setting
base to different reapply_*() functions is more complicated, albeit incorrect
in complex cases. We need full control over how to reapply changes, one
after the other.
Also, once we start applying changes, we cannot really abort on error.
We can only continue best-effort and hope for the best.
Also, always reapply certain settings, even if the configuration doesn't
change. That means, if the user externally deletes a static IP address,
he can call reapply() to restore it. Even though he doesn't provide a
different setting to apply.
Also revert the changes to nm_device_reapply_settings_immediately().
Effectively there is little code that can be reused.
Add audit logging.
In certain situations, ethernet links first appear with a zero MAC
address and then the MAC changes some time later. Currently NM does
not deal correctly with this scenario since it initializes wrong
@initial_hwaddr and @permanent_hwaddr on the device and tries to
immediately activate it.
To fix this, initialize the device's addresses only when the MAC
becomes valid and make the device available only at that point.
Instead of using a signal for triggering the generation of a default
connection when the device becomes managed, let the manager wait for a
transition to UNAVAILABLE or DISCONNECTED states.
This partially reverts b3b0b46250 ("device: retry creation of
default connection after link is initialized").
