When we have a GError* variable on the stack, we usually want to pass
it on to function that can fail. In that case, the variable MUST be
initialized to NULL. This is an easy mistake to make.
Note that this check still can have lots of false positives, for
example, if you have a struct with an GError field. In that case, you
would need to ensure that the entire struct is initialized. Ignore the
warning then.
Also, the check misses if you declare multiple variables on one line.
But that is already discouraged by our style.
When cloud-init job (metadata service crawler) starts, it sends the
SIGTERM signal to nm-cloud-setup and force the nm-cloud-setup to
restart, however, because the error is not initialized as NULL in
`_init_start_cancelled_cb()` before it is set, nm-cloud-setup will hit
a dumped core.
TO fix it, initialize the error as NULL in `_init_start_cancelled_cb()`.
https://bugzilla.redhat.com/show_bug.cgi?id=2027674
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
Backtrace:
#0 g_logv (log_domain=0x7f833a872071 "GLib", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../glib/gmessages.c:1413
#1 0x00007f833a81f043 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at ../glib/gmessages.c:1451
#2 0x00007f833ab97230 in nm_utils_error_set_cancelled (is_disposing=<optimized out>, instance_name=<optimized out>, error=0x7ffff79cb980) at src/libnm-glib-aux/nm-shared-utils.c:2599
#3 nm_utils_error_set_cancelled (is_disposing=0, instance_name=0x0, error=0x7ffff79cb980) at src/libnm-glib-aux/nm-shared-utils.c:2590
#4 _init_start_cancelled_cb (cancellable=<optimized out>, user_data=0x5640ca292150) at src/libnm-client-impl/nm-client.c:7324
#5 _init_start_cancelled_cb (cancellable=<optimized out>, user_data=0x5640ca292150) at src/libnm-client-impl/nm-client.c:7307
#6 0x00007f833a93094a in _g_closure_invoke_va (param_types=0x0, n_params=<optimized out>, args=0x7ffff79cbb40, instance=0x5640ca267020, return_value=0x0, closure=0x5640ca29d430)
at ../gobject/gclosure.c:873
#7 g_signal_emit_valist (instance=0x5640ca267020, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffff79cbb40) at ../gobject/gsignal.c:3406
#8 0x00007f833a930a93 in g_signal_emit (instance=instance@entry=0x5640ca267020, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3553
#9 0x00007f833a9a6475 in g_cancellable_cancel (cancellable=0x5640ca267020) at ../gio/gcancellable.c:513
#10 g_cancellable_cancel (cancellable=0x5640ca267020) at ../gio/gcancellable.c:487
#11 0x00005640ca1a8bd4 in sigterm_handler (user_data=0x5640ca267020) at src/nm-cloud-setup/main.c:599
#12 0x00007f833a819d4f in g_main_dispatch (context=0x5640ca268ef0) at ../glib/gmain.c:3337
#13 g_main_context_dispatch (context=0x5640ca268ef0) at ../glib/gmain.c:4055
#14 0x00007f833a86e608 in g_main_context_iterate.constprop.0 (context=0x5640ca268ef0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4131
#15 0x00007f833a819463 in g_main_loop_run (loop=0x5640ca24fdb0) at ../glib/gmain.c:4329
#16 0x00005640ca1a6d04 in nmc_client_new_waitsync (cancellable=0x5640ca267020, out_nmc=0x7ffff79cbfa0, error=0x7ffff79cbf98, first_property_name=0x5640ca1b11db "instance-flags",
first_property_name=0x5640ca1b11db "instance-flags") at src/libnm-client-aux-extern/nm-libnm-aux.c:129
#17 0x00005640ca1a3863 in main (argc=1, argv=<optimized out>) at src/nm-cloud-setup/main.c:639
Pass the full hostname to the DNS manager, so that the domain gets
added to resolv.conf even when the hostname was truncated.
Note that "hostname" argument for plugins's update() function is
currently unused. Don't remove that because it can be potentially
useful to set a global search domain based on the hostname, but change
it to carry the domain directly.
Before, we would just ignore the errors when we passed an invalid value
to a property alias:
$ nmcli c add type ethernet mac Hello
Connection 'ethernet-1' (242eec76-7147-411a-a50b-336cf5bc8137) successfully added.
$ nmcli c show 242eec76-7147-411a-a50b-336cf5bc8137 |grep 802-3-ethernet.mac-address:
802-3-ethernet.mac-address: --
...or crash, because the GError would still be around:
$ nmcli c add type ethernet mac Hello ethernet.mac-address World
(process:734670): GLib-WARNING **: 14:52:51.436: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error: failed to modify 802-3-ethernet.mac-address: 'World' is not a valid Ethernet MAC.
Error: failed to modify 802-3-ethernet.mac-address: 'Hello' is not a valid Ethernet MAC.
Now we catch it early enough:
$ nmcli c add type ethernet mac Hello
Error: failed to modify 802-3-ethernet.mac-address: 'Hello' is not a valid Ethernet MAC.
Fixes: 40032f4614 ('cli: fix resetting values via property alias')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1134
This allows to fetch the information about the AP that CSME if connected
to. It'll allow us to connect to the exact same AP and shaving off the
scan from the connection, improving the connection time.
nm_l3_config_data_new_clone() takes non-positive ifindex to use
the ifindex of the l3cd. But it also asserts that the ifindex
is not negative. Fix that assertion failure, by setting the ifindex
to zero.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/907
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
Currently it is possible to specify a list of default settings plugins
to be used when configuration doesn't contain the main.plugins key.
We want to add a mechanism that allows to automatically load any
plugin found in the plugins directory without needing
configuration. This mechanism is useful when plugins are shipped in a
different, optional subpackage, to automatically use them.
With such mechanism, the actual list of plugins will be determined
(in order of evaluation):
1. via explicit user configuration in /etc, if any
2. via distro configuration in /usr, if any
3. using the build-time default, if any
4. looking for known plugins in /usr/lib
Don't log the failure to spawn the auth dialog. This is polluting the
terminal when using nmcli when activating an OpenVPN profile if
/usr/libexec/nm-openvpn-auth-dialog is not available. Since nmcli can
still ask for the credentials, the missing auth dialog does not block
the activation, so the "warning" level is too much. Since it is a
library, any output to the terminal is bad, therefore remove the
logging.
Signed-off-by: Till Maas <opensource@till.name>
Hope third time is the charm.
The idea here is to remove the OVSDB entry if the device actually went away
violently (like, the it was actually removed from the platform), but keep it if
we're shutting down.
Fixes-test: @ovs_nmstate
Fixes: 966413e78f ('ovs-port: avoid removing the OVSDB entry if we're shutting down')
Fixes: ecc73eb239 ('ovs-port: always remove the OVSDB entry on slave release')
https://bugzilla.redhat.com/show_bug.cgi?id=2055665
It's helpful to control when data/state gets mutated. In particular,
when passing on a pointer via several hops. C can help with that
at compile time via "const".
But the "index" field of APInfo is actually mutable, as it counts
the lines. So most of the data is immutable, but the index.
Make APInfo const. But to do that, the mutable part must be moved to a
separate place.
Also, start with the counter initialized to zero instead of one.
It is just nicer.
On the D-Bus API, the current access point is referred exactly, by its
D-Bus path. Likewise, in libnm's NMClient cache, the access point
instance is unique in representing the D-Bus object (meaning, we
can directly use pointer equality).
Let's not compare the active AP based on the BSSID. It can happen
that the scan list contains the same BSSID multiple times (for example
on different bands). In that case, the output should only highlight
one AP as in-use:
$ nmcli device wifi list
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
* E4:0f:4b:2a:c3:d1 MYSSID1 Infra 6 270 Mbit/s 100 ▂▄▆█ WPA2
* E4:0f:4b:2a:c3:d1 MYSSID1 Infra 6 270 Mbit/s 87 ▂▄▆█ WPA2
For one, this API is only available since 2.72, thus we must not use
it (unless we would add a compat implementation to nm-glib.h).
But also, g_alloca0() evaluates the size argument multiple times,
making it non-function like. That seems highly undesirable and error
prone.
Also, we should be very careful about alloca() and the potential
for stack overflow. We use alloca() at times, but usually with
macros that are named "*_a()" (to make the danger clearer) and compile
time checks for the size. These glib functions make this slightly
less safe.
Just prevent us from using this API.
When we have a bridge interface with ports attached externally (that is,
not by NetworkManager itself), then it can make sense that during
checkpoint rollback we want to keep those ports attached.
During rollback, we may need to deactivate the bridge device and
re-activate it. Implement this, by setting a flag before deactivating,
which prevents external ports to be detached. The flag gets cleared,
when the device state changes to activated (the following activation)
or unmanaged.
This is an ugly solution, for several reasons.
For one, NMDevice tracks its ports in the "slaves" list. But what
it does is ugly. There is no clear concept to understand what it
actually tacks. For example, it tracks externally added interfaces
(nm_device_sys_iface_state_is_external()) that are attached while
not being connected. But it also tracks interfaces that we want to attach
during activation (but which are not yet actually enslaved). It also tracks
slaves that have no actual netdev device (OVS). So it's not clear what this
list contains and what it should contain at any point in time. When we skip
the change of the slaves states during nm_device_master_release_slaves_all(),
it's not really clear what the effects are. It's ugly, but probably correct
enough. What would be better, if we had a clear purpose of what the
lists (or several lists) mean. E.g. a list of all ports that are
currently, physically attached vs. a list of ports we want to attach vs.
a list of OVS slaves that have no actual netdev device.
Another problem is that we attach state on the device
("activation_state_preserve_external_ports"), which should linger there
during the deactivation and reactivation. How can we be sure that we don't
leave that flag dangling there, and that the desired following activation
is the one we cared about? If the follow-up activation fails short (e.g. an
unmanaged command comes first), will we properly disconnect the slaves?
Should we even? In practice, it might be correct enough.
Also, we only implement this for bridges. I think this is where it makes
the most sense. And after all, it's an odd thing to preserve unknown,
external things during a rollback -- unknown, because we have no knowledge
about why these ports are attached and what to do with them.
Also, the change doesn't remember the ports that were attached when the
checkpoint was created. Instead, we preserve all ports that are attached
during rollback. That seems more useful and easier to implement. So we
don't actually rollback to the configuration when the checkpoint was
created. Instead, we rollback, but keep external devices.
Also, we do this now by default and introduce a flag to get the previous
behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=2035519https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ # 909
What nm_uuid_generate_from_string() does, is pretty straight forward.
What nm_crypto_md5_hash() does, is not.
Just directly use GChecksum, it seems clearer.
Also, sometimes the compiler is adamant to warn about uninitialized variables.
The workaround from commit cb9ca67901 ('glib-aux: workaround maybe-uninitialized
warning with LTO in nm_uuid_generate_from_string_str()') does not always work.
Try to solve that this way.
Note that we have plenty of unit tests for our UUID generation. This is
covered by tests.
Also, there is now only one caller of nm_crypto_md5_hash() left. Which
is good, because that function is rather non-obvious and special purpose.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1129
NetworkManager-wait-online is a constant source of confusion,
as it seems to delay the boot (when it's often just the messenger
or either a network problem, a NetworkManager misconfiguration
or a misconfiguration of other systemd services).
Try to clear that up with a manual page.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1130
People keep reporting bugs with `level=DEBUG` or set to a certain
domains. That is generally not useful. Complete debug logs should be
collected, we can always ignore what we don't care about, but we might
miss important information by limiting what we collect.
Try to make that clearer in the manual.
For devices that configure IP by themselves (by returning
"->ready_for_ip_config() = TRUE" and implementing
->act_stage3_ip_config()), we skip manual configuration. Currently,
manual configuration is the only one that sets flag HAS_DNS_PRIORITY
into the resulting l3cd.
So, the merged l3cd for such devices misses a dns-priority and is
ignored by the DNS manager.
Explicitly initialize the priority to 0; in this way, the default
value for the device will be set in the final l3cd during the merge.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/931
The kernel may add a reason for hardware rfkill. Make the NetworkManager
able eto fetch it and parse it.
For now, no action will be taken upon the new reasons.
The different reasons that the kernel can expose are either the radio
was switched off by a hardware rfkill switch. This reason is adveritsed
by bit 0 in the bitmap returned by RFKILL_STATE_REASON udev property.
This is the rfkill that existed until now.
The new reason is mapped to bit 1 and teaches the user space that the
wifi device is currently used by the CSME firmware on the platform. In
that case, the NetworkManager can ask CSME (through the iwlmei kernel
module) what BSSID the CSME firmware is associated to. Once the
NetworkManager gets to the conclusion is has the credentials to connect
to that very same AP, it can request the wifi device and the CSME
firmware will allow the host to take the ownership on the device. CSME
will give 3 seconds to the host to get an IP or it'll take the device
back. In order to complete all the process until we get the DHCP ACK
within 3 seconds, the NetworkManager will need to optimize the scan and
limit the scan to that specific BSSID on that specific channel.
All this flow is not implemented yet, but the first step is to identify
that the device is not owned by the host.
This paragraph that "it's likely that" some changes will be backported
to 1.34 branch seems unnecessary. Whenever we backport things to 1.34
we will add them to the NEWS file for nm-1-34, and then also mention
them in nm-1-36 and newer. But we don't need to announce that.
