The bond option ad_actor_system only matters (and is available) with
mode=802.3ad.
When you create a new bond, the sysctl value will be set to "00:00:00:00:00:00".
So this seems to be a valid value, and in fact the default value for
this option. However, kernel will fail with EINVAL to set the sysctl to
"00:00:00:00:00:00". Kernel fails both if the value is already
"00:00:00:00:00:00" (i.e. setting the same value results in an error) and
it also fails otherwise (i.e. we cannot ever reset the value to
"00:00:00:00:00:00", at least not via sysfs).
Avoid the warning in the common case, where the value is already as
expected.
Otherwise, we still get the warning and won't be able to set the right
value. But this is really a limitation of the kernel API where we cannot
do anything about it (in NetworkManager).
https://bugzilla.redhat.com/show_bug.cgi?id=1923999
fixes segfault with iwd backend after upgrade to NetworkManager 1.30.0
Signed-off-by: Jan Palus <jpalus@fastmail.com>
Fixes: 43fd93d8f4 ('iwd: Order objects from g_dbus_object_manager_get_objects')
glib requires G_LOG_DOMAIN defined so that log messages are labeled
to belong to NetworkManager or libnm.
However, we don't actually want to use glib logging. Our library libnm
MUST not log anything, because it spams the user's stdout/stderr.
Instead, a library must report notable events via its API. Note that
there is also LIBNM_CLIENT_DEBUG to explicitly enable debug logging,
but that doesn't use glib logging either.
Also, the daemon does not use glib logging instead it logs to syslog.
When run with `--debug`.
Hence, it's not useful for us to define different G_LOG_DOMAIN per
library/application, because none of our libraries/applications should
use glib logging.
It also gets slightly confusing, because we have the static library like
`src/libnm-core-impl`, which is both linked into `libnm` (the library)
and `NetworkManager` (the daemon). Which logging domain should they use?
Set the G_LOG_DOMAIN to "nm" everywhere. But no longer do it via `-D`
arguments to the compiler.
See-also: https://developer.gnome.org/glib/stable/glib-Message-Logging.html#G-LOG-DOMAIN:CAPS
"libnm-core/" is rather complicated. It provides a static library that
is linked into libnm.so and NetworkManager. It also contains public
headers (like "nm-setting.h") which are part of public libnm API.
Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
only rely on public API of libnm-core, but are themself static
libraries that can be used by anybody who uses libnm-core. And
"libnm-core/nm-libnm-core-intern" is used by libnm-core itself.
Move "libnm-core/" to "src/". But also split it in different
directories so that they have a clearer purpose.
The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
directories correspond to the different modules (static libraries and set
of headers that we have). We have different kinds of such modules because
of how we combine various code together. The directory layout now reflects
this.
We periodically re-resolve the DNS name for entpoints. Since WireGuard
has no concept of being connected, we want to eventually pick up
if the DNS name resolves to a different IP address.
However, on resolution failure, we will never clear the endpoint we
already have. Thus, resolving names can only give a better endpoint,
not remove an IP address entirely.
DNS names might do Round-Robin load distribution and the name of the
endpoint might resolve to multiple IP addresses. Improve to stick to
the IP address that we already have -- provided that the IP address
is still among the new resolution result. Otherwise, we continue to
pick the first IP address that was resolved.
(cherry picked from commit 98348ee539)
Don't request new copies of strings from g_variant_get() to avoid
leaking memory as pointed out by Thomas Haller.
Fixes: dc0e31fb70 ('iwd: Add the wifi.iwd.autoconnect setting')
(cherry picked from commit 5ccb8ce17a)
On copr build, it seems possible that the ioctl fails with
ERROR: src/core/devices/tests/test-lldp - Bail out! NetworkManager:ERROR:src/core/devices/tests/test-lldp.c:823:_test_recv_fixture_setup: assertion failed (errno == 0): (1 == 0)
(1 is EPERM). Unclear why this happens. But as it only affects the
test setup, retry a few times.
IWD's "open" networks can be either unsecured or use OWE and "psk"
networks may be using WPA2 personal or WPA3 personal so when looking for
an exsiting NMSettingsConnection matching an IWD KnownNetwork, also
check for these connection key_mgmt types.
Add explicit checks for AP and ADHOC connection modes to exclude OWE and
SAE as they're not supported by IWD in those modes and we don't want to
make it appear like a connection of this type was successfully
activated.
In Infrastructure mode there's won't be any way to know whether IWDxi
established an OWE or unsecured connection (or WPA2-PSK vs. SAE)
regardless of what was set in the NMConnection and it's not considered
to be meaningful (also isn't normally exposed in a GUI) although you
could argue OWE vs. unsecured is a big difference.
IWD doesn't expose on D-Bus, or in the network profile files, the
information on whether a network has no security or uses OWE so they
should be the same thing to the iwd backend (similarly WPA2-Personal and
WPA3-Personal/SAE). But OWE implies some security against some attacks
so the NONE naming could be misleading.
Currently if we detect that a scan finished in
_scan_notify_is_scanning(), we call immediately _scan_kickoff() (which
might start a new scan) and then we check again whether the device can
autoactivate or whether to remove the wifi-scan pending action.
This means that if the scan takes long enough, when
_scan_notify_is_scanning() is called, it is already time to start
another scan and the device activation will be delayed. It will be
delayed until the scan duration becomes shorter than the
exponentially-growing periodic scan interval.
Fix this by delaying the next scan immediately after a scan result.
Co-authored-by: Thomas Haller <thaller@redhat.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/574
Our cast macros (like NM_AUTH_SUBJECT()) are plain C pointer casts,
unless when building with more asserts enabled.
Still, they are unnecessary and even their ability to check the type
(with more asserts) is not needed, because we must trust glib's
g_object_new() to return reasonable objects. That is a basic
requirement, that we don't need to assert against.
Also, in the majority of cases we don't do this either.
The ifindex of a virtual device is set when the kernel link
appears. For OVS interfaces, this happens after NM has added the
record to the ovsdb; since NM needs to know the related port and
bridge when it adds ovs-interface record, and since interfaces are
enslaved when they reach stage3, the ifindex is set during stage3.
This means that the first time
nm_device_activate_schedule_stage3_ip_config_start() is called, the
ifindex is unset. Previously we would just set the firewall state as
initialized and the zone would never be set again. Instead, allow the
zone to be set when re-entering stage3.
nm_device_activate_schedule_stage3_ip_config_start() now always check
for the ifindex. This guarantees that we don't try to change zone for
devices without a kernel link (for example, OVS bridges and ports).
Upon reaching state ip-check, the device now changes the zone also if
an ifindex is present and the zone was not set before. I'm not sure
this can actually happen, because if the device has an ifindex it
should be set during stage3. However I'm leaving this extra check for
completeness.
https://bugzilla.redhat.com/show_bug.cgi?id=1921107https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/737
Failing the system interface device is almost always the right thing
to do when the ovsdb entry is removed.
However, to avoid that a late device-removed signal tears down a
different, newly-activated connection, let's also check that we have a
master. Or in alternative, that the device is assumed/external: in
such case it's always fine to fail the device
Fixes: 8e55efeb9d ('ovs: fail OVS system interfaces when the db entry gets removed')
https://bugzilla.redhat.com/show_bug.cgi?id=1923248https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/741
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.
Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.
We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.
As the name "src/" is already taken, that prevents any sensible
restructuring of the code.
As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".
For inspiration, look at systemd's "src/" directory.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
