Don't change the address order from configuration, but instead sort
addresses just before returning them to clients.
(cherry picked from commit 0a0bca9c7f)
Don't change the address order from configuration, but instead sort
addresses just before returning them to clients.
(cherry picked from commit 9609d4da1d)
When multiple address are assigned to an interface and the kernel must
decide which one should be used to communicate with a given IP, it
chooses the most specific one in the same subnet as the
destination. In case there are multiple addresses in the same subnet,
the primary address is choosen, which is basically the first one that
was added.
With commit 7197425137 ("device: expose NMIP4Config:addresses in
stable/defined sort order") we sorted all the addresses before
committing the configuration, with the side effect that the order no
longer respected the one in the user configuration.
Instead, change the sort function to keep the subnet order unchanged.
(cherry picked from commit e02752c2ed)
Don't let a later property update finish than the sooner one.
This wouldn't happen most of time, apart from a special case when the
latter update of a object array property is to an empty list.
In that case the latter update would complete sooner and when the
earlier update finishes the list would contain objects which are
supposed to be gone already.
(cherry picked from commit 7007c9853c)
Since commit 9fafb382db, we would
explicitly set libnl's socket buffer size to 4*getpagesize().
That is also the default of libnl itself. Additionally, we would
workaround too small buffers by increasing the buffer size up to 512K.
A too small buffer causes messages to be lost. Usually, that only
results in a cache-resync, which isn't too bad. Lost messages are however
a problem if the lost message was an ACK that we were waiting for.
However, it is rather unlikely to happen, because it's expected that
the buffer size gets adjusted already when the cache is filled initially,
before any other requests are pending.
Still, let's increase the default buffer size to 32K, hoping that this
initial value is already large enough to avoid the problem altogether.
Note that iproute2 also uses a buffer size of 32K [1] [2].
Alternatively, we could use MSG_PEEK like systemd does [3]. However,
that requires two syscalls per message.
[1] https://patchwork.ozlabs.org/patch/592178/
[2] https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/tree/lib/libnetlink.c?id=f5f760b81250630da23a4021c30e802695be79d2#n274
[3] cd66af2274/src/libsystemd/sd-netlink/netlink-socket.c (L323)
(cherry picked from commit ed82b6bcb3)
Autoconnect property doesn't really matter for the applied
connection. Whitelist it from the properties and allow changing
it during reapply.
(cherry picked from commit d29839c430)
We don't want to enable MSG_PEEK due to the overhead. But when we detect
that we just lost a message due to MSG_TRUNC, increase the buffer size and
retry.
See-also: 55ea6e6b6c
(cherry picked from commit 9fafb382db)
From valgrind:
==21921== Invalid free() / delete / delete[] / realloc()
==21921== at 0x4C2CD5A: free (vg_replace_malloc.c:530)
==21921== by 0x81C4F2D: g_free (gmem.c:189)
==21921== by 0x81AB021: g_error_free (gerror.c:491)
==21921== by 0x81AB325: g_clear_error (gerror.c:674)
==21921== by 0x767B555: reg_request_cb (nm-secret-agent-old.c:616)
==21921== by 0x7A211F2: g_task_return_now (gtask.c:1107)
==21921== by 0x7A21228: complete_in_idle_cb (gtask.c:1121)
==21921== by 0x81BF6B9: g_main_dispatch (gmain.c:3154)
==21921== by 0x81BF6B9: g_main_context_dispatch (gmain.c:3769)
==21921== by 0x81BFA6F: g_main_context_iterate.isra.29 (gmain.c:3840)
==21921== by 0x81BFB1B: g_main_context_iteration (gmain.c:3901)
==21921== by 0x7A4748C: g_application_run (gapplication.c:2381)
==21921== by 0x118AEF: main (main.c:81)
It caused memory corruption and may result in strange nm-applet crashes.
(cherry picked from commit 544f7d3683)
We may want to stop the plugin before we started connecting e.g. when the
plugin NeedsSecrets but we can't supply them.
(cherry picked from commit 743d372d72)
Plugins could be already failed or disconnected when the helper fires.
E.g. they could send in an invalid IP4Config that would cause them to
fail and then follow with an IP6Config before they realize it's of no
use. We'd hit an assertion failure in that case, because the
NMVpnConnection would already be cleaned up.
(cherry picked from commit bf70ed2e86)
This gives the templates a chance to do something extra clever with the
formatting. The templates, of course, choose not to :(
(cherry picked from commit 7b589e2b72)
Also, be a bit more careful about the layers of errors. Just don't do this:
(process:236): nmcli-CRITICAL **: Error: Could not create NMClient object:
Permissions request failed: Authorization check failed:
The name org.freedesktop.PolicyKit1 was not provided by any .service files.
(cherry picked from commit 7279ea1317)
Otherwise its path remains visible on D-Bus despite the object is gone,
making libnm sad and grumpy:
libnm-WARNING **: no object known for /org/freedesktop/NetworkManager/AccessPoint/666
(cherry picked from commit d0c01cc79d)
When going to sleep, we unmanage devices setting the unmanaged flags
immediately but delaying the state transition (because we do it from
another state transition). The signal handler can be executed after
the wake and, especially, after we have already re-managed the device,
making the device unmanaged again.
Detect such situation and force the state to UNMANAGED (which will
also clear any pending state change), so that later we manage the
device again and it will try to activate any available connection.
Fixes: 81ea812362
(cherry picked from commit 3cc06c3db679c1ff2f61a301396393300d36adbb)
The interaction between the manager state and connectivity check code
is tricky. When there is an active connection with a default route and
NMConnectivity reports full connectivity, we set the CONNECTED_GLOBAL
state. However, if the connectivity check hasn't run yet, we stay in
CONNECTED_SITE state. If there are also other connections that are
activating, the state is set to CONNECTING.
This is a problem, because in CONNECTING we never run the connectivity
check and thus we fail to recognize that there is full connectivity
until a periodic check is run.
To solve this, schedule the connectivity check every time there is an
active connection with default route, even if other connection are
still activating, so that the check result can make the state progress
to CONNECTED_GLOBAL.
(cherry picked from commit 084da69a30)
For example for tun devices we get a lot of
(tun7): hw-addr: failed reading current MAC address
warnings. Just be silent about it. We log when something
changes, we don't need to log when we fail to obtain
a MAC address.
Thereby, refactor nm_device_update_hw_address() to return early.
(cherry picked from commit 0e0018c801)
Conflicts:
src/devices/nm-device.c
The unmanaged flags PLATFORM_INIT indicates whether UDEV is done
initializing the device. We should not handle IP config changes
before that pointer.
This avoids codepaths that require the permanent MAC address of the
device. We should not freeze the permanent MAC address before
UDEV initialized the device, for two reasons:
- getting the permanent MAC address using ethtool is racy as
UDEV might still rename the interface.
- freezing a fake permanent MAC address should only happen after
UDEV is done configuring the MAC address of software devices.
#0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817
#1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0)
at src/devices/nm-device.c:12227
#2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237
#3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294
#4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461
#5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277
#6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169
#7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234
#8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142
#9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161
#10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0)
at src/devices/nm-device.c:4787
#11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532
#12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651
#13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154
#14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769
#15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034
#17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
(cherry picked from commit 31ca7962f8)
Before the link is initialized, that is before UDEV completed
initializing the device, we should not evaluate the user-settings
unmanaged flags.
The reason is, that evaluating it likely involves looking at the
permanent MAC address, which might use the wrong fake MAC address
(before UDEV set the right one). Also, it might use the wrong ifname
to lookup the permanent MAC address via ethtool.
(cherry picked from commit c0d249b733)
The permanent MAC address of an NMDevice shall not change as
long as the device is realized. That is, we read it only once
and don't change it afterwards.
There are two issues that this commit tries to mitigate:
(1) users are advised to use UDEV to rename interfaces. As we lookup
the permenent MAC address using ethtool (which uses the interface
name), there is a race where we could read the permanent MAC
address using the wrong interface name. We should wait until
UDEV finished initializing the device and until the interface
name is stable (see rh#1388286).
This commit still cannot avoid the race of ethtool entirely. It only
tries to avoid ethtool until UDEV has done its work. That is, until we
expect the interface name no longer to change.
(2) some device types, don't have a permanent MAC address so we fall
back to use the currently set address (fake). Again, users are advised
to use UDEV to configure the MAC addresses on such software devices.
Thus, we should not get the fake MAC address until UDEV initialized
the device.
This patch actually doesn't solve the problem at all yet.
The reason is that a regular caller of nm_device_get_permanent_hw_address() can
not afford to wait until UDEV settled. Thus, any user who requests the
permanent MAC address before the link is initialized, runs into the
problems above.
In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address()
and delay them until the link is initialized.
(cherry picked from commit 7b7c653c4f)
Conflicts:
src/devices/nm-device.c
src/nm-manager.c
We repeatedly call nm_device_update_hw_address() to reset the cached
MAC address of the device. However, we don't allow changing the address
length once it is set.
Multiple entities (initial, current and permanent MAC address) are all
checked to have the same address length. Changing the length would be a
very strange thing (and probably indicate a bug somewhere else).
Just don't allow that.
(cherry picked from commit cbea1f9f23)
Now that we persist the fake permanent address across
restart of NetworkManager, we want to consider fake
addresses as good enough in most cases.
(cherry picked from commit 416164aa29)
The default wired connection is already generated allowing the use of a fake
address, but for the state file and the device matching specs only non-fake
addresses are used. Let's allow fake addresses consistently, so that default
wired connections work properly in containers (where the veth address is
considered fake) as well.
Also, it would really be a better idea to use ifnames everywhere instead, but
that would change the format of the state file.
(cherry picked from commit bcb685c4cb)
_nm_utils_hwaddr_length() did a validation of the string
and returned the length of the address. In all cases where
we were interested in that, we also either want to validate
the address, get the address in binary form, or canonicalize
the address.
We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton()
which both does the parsing and returning the length.
(cherry picked from commit e5fe5a4c03)
We usually don't build NM with g_assert() disabled (G_DISABLE_ASSERT).
But even if we would, there is no assertion macro that always evaluates
the condition for possible side effects.
I think that is a useful thing to have.
(cherry picked from commit ba950cedee)
When running
NMTST_NO_VALGRIND=1 make check -j
we would not start separate D-Bus sessions, thus running tests with
valgrind enabled failed.
(cherry picked from commit c94dac0b5d)
Since commit 1495853e01, LOGD_HW is renamed to
LOGD_PLATFORM. Remove the internal usage of the deprecated name.
Backport this patch to nm-1-4 because it avoids follow-up conflicts with
future backports. Also, it is a really trivial change, meaning, we only
replace the obsolte LOGD_HW name.
(cherry picked from commit 64951f07fb)
Conflicts:
src/devices/nm-device.c
src/devices/wwan/nm-modem.c
nm_settings_connection_set_autoconnect_blocked_reason() must be called
on the settings-connection. Fixes the following:
GLib-GObject-WARNING **: invalid cast from 'NMSimpleConnection' to 'NMSettingsConnection'
Fixes: 06da353242
(cherry picked from commit 7034ea7aa3)
It was a macro to pass on the non-const-ness of the argument, but
that just doesn't make sense.
That is a signature
char *nm_str_not_empty (char *)
does not make sense, because you cannot transfer ownership
conditionally without additional checks to avoid a leak. Which makes
this form is pointless. For example:
char *
foo (void)
{
char *s;
s = _create_value ();
return nm_str_not_empty (s); /* leaks "" */
}
(cherry picked from commit 34970e4141)
Depending on how arguments are passed to the called function,
this could lead to a crash.
Maybe not on 32 bit machines where the size of the pointer is
the size of an int.
Maybe not on x86_64, where the arguments are passed in registers.
Fixes: b88c309167
(cherry picked from commit 548a5440e9)
