I guess the idea was to only accept options that can be changed without
taking the interface !IFF_UP. "active_slave" is wrongly omitted from
that list.
Also, "active_slave" option doesn't really make sense for NetworkManager
to configure. Instead "primary" should be used. In the future, we should
re-map the properties and deprecate "active_slave" for "primary" ([1]).
Fixes: 746dc119a6 ('bond: let 'reapply()' reapply all supported options')
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1856640#c19https://bugzilla.redhat.com/show_bug.cgi?id=1876577
WireGuard's wg-quick primarily wants to avoid DNS leaks, and thus also
our import code should generate profiles that configure exclusive DNS
servers. This is done by setting "ipv[46].dns-priority" to a negative
value.
Note that if a profile leaves the DNS priority at zero (which in many
regard is the default), then the zero translates to 50 (for VPN
profiles) and 100 (for other profiles).
Instead of setting the DNS priority to -10, set it to -50. This gives
some more room so that the user can choose priorities that are worse
than the WireGuard's one, but still negative (exclusive). Also, since
the positive range defaults to 50 and 100, let's stretch the range a
bit.
Since this only affects import and creation of new profiles, such a
change in behavior seems acceptable.
more_asserts are our NetworkManager specific assertions, and the only
point of having them at all (beside g_assert(), assert() and g_return*()),
is that these assertions are disabled by default in production.
meson always enabled them by default. That is definitely wrong.
autotools enables more_asserts by default if we build a devel version
from master. I think that is bad too, because (again) having these assertions
disabled by default is the only point of having them. Anyway, mimic
the behavior of autotools, to at least disable them in release builds.
On Fedora rawhide (34), valgrind gives a lot of warnings like:
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- WARNING: unhandled amd64-linux syscall: 439
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- You may be able to write your own handler.
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- Nevertheless we consider this a bug. Please report
./src/platform/tests/test-cleanup-linux.valgrind-log:--48279-- it at http://valgrind.org/support/bug_reports.html.
Ignore them.
NMDBusObject is an abstract type which provides the glue code for exposing
a GObject on D-Bus. We almost never use that type directly, so as it was
before, we always had to use a C cast to convince the compiler that this
is right.
Being always required to cast is not very useful, nor more typesafe.
Just use a void pointer instead.
NML3Cfg manages one ifindex. In the future, we may want that multiple
NMDevice and/or NMVpnConnection instances independently contribute their
NML3ConfigData to the NML3Cfg instance.
That means, at any time somebody may want to call nm_l3cfg_platform_commit()
to apply the changes. Even ACD internally may do that, when configuration
changes (e.g. an IP address passes ACD check). We thus need to know
whether we are assuming, updating or reapplying the settings.
Add API so users can register their "commit" preference.
The current approach also tracks external configuration in an NMIP[46]Config, and
we need to special handle those. In the future, we only want to track what we actually
want to configure. So this flag won't be used with NML3Cfg/NML3ConfigData.
Currently, NMDevice does ACD. It intercepts certain NMIP4Config
instances, and tries to perform ACD on the addresses. I think this
functionality should be handled by NML3Cfg instead.
For one, NML3Cfg sees all configurations, and can perform ACD for all
(relevant) addresses. Also, it moves logic away from NMDevice and makes
the functionality available without an NMDevice. As such, it also will
allow that independent "controllers" contribute NML3ConfigData instances
and ACD will performed for all of them (as requested).
This will be our implementation for IPv4 ACD (https://tools.ietf.org/html/rfc5227)
based on nettools' n-acd library.
The code is not actually tested yes, because NMDevice did not yet switch
over to use NML3Cfg. Once that happens, surely issues with this patch
will be found that will need fixing.
Having leaks in the tests, breaks running the test under valgrind. There
must be no leaks.
Fixes: c056cb9306 ('initrd: parse 'rd.net.dhcp.vendor-class' kernel cmdline arg')
We still use the "gs_*" macros that we originally got from libgsystem.
libgsystem no longer exists, we only still use the names of these
macros.
Our own cleanup macros all follow the "nm_auto*" naming pattern.
Eventually, we want to replace all uses of "gs_*" with cleanup macros
that follow our naming scheme.
Add the macros that will be used to replace the "gs_*" macros.
The "gs_*" macros originate from the (no longer existing) libgsystem library.
We still have them, because so far we didn't go through the effort of
renaming the API.
Aside that oddity, our cleanup API is called "nm_auto*". There is no need
to add new API with the old name.
