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)
The file, imported from systemd sources, contains macros for accessing
potentially unaligned data in a safe way (i.e. byte-wise).
(cherry picked from commit 22cc119da5)
We connect signal handlers to devices when they appear, but don't
disconnect the handlers when the manager instance is destroyed. This
can cause crashes as device_ac_changed() is called on an invalid
manager instance.
Disconnect the handlers from dispose().
https://bugzilla.redhat.com/show_bug.cgi?id=1383758
(cherry picked from commit 0a61317870)
The @assoc_cancellable was never initialized and thus ineffective; fix
this.
Furthermore, we only cancel it in nm_supplicant_interface_disconnect()
as we expect that clients call the function before destroying the
interface. Don't assume this and also cancel it in dispose().
https://bugzilla.redhat.com/show_bug.cgi?id=1383628
(cherry picked from commit 0539725aef)
Since commit ac888de151 ("cli/connections: fail the activation when
the active connection disappears") we rely only on the disappearing of
the active-connection to determine the failure of an activation.
libnm can collapse a 'added' and a 'removed' signal if they are
received closer enough and thus we may miss the removal of the active
connection. Restore the detection of failure based on
active-connection state.
(cherry picked from commit 79a357b07a)
Previously, when the load of an object failed and there were other
objects waiting for it, those objects would remain waiting
forever. Make them fail as well.
(cherry picked from commit f4a0ab757f)
Some TTY drivers or devices appear to ignore port speed and always
report zero. Technically this means the port is hung up and control
lines should be disconnected, but with USB devices many of the serial
port attributes are meaningless and ignored by some devices.
pppd requires the port's speed to be greater than zero, and will
exit immediately when that is not the case, even though these
modems will work fine. Passing an explicit speed to pppd in this
case works around the issue, as pppd attempts to set that speed
on the port and doesn't actually care if that operation fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1281731
(cherry picked from commit 01de14b1ddcd011ebc2f4676e5950b9ec890c698)
