If previously the profile would track two addresses ("10.116.1.130/24",
"10.116.1.65/24"), and during an update the second address was removed
(leaving "10.116.1.130/24"), then the addresses of the profile were
wrongly not changed.
The effect is that removing a secondary IP address might not take
effect.
Fix that.
https://bugzilla.redhat.com/show_bug.cgi?id=1920838
Fixes: 69f048bf0c ('cloud-setup: add tool for automatic IP configuration in cloud')
No big change, but eventually I' like to move all source
directories under src/. That must be done one after the other,
so the first step is to move libnm-core/ into src/. If libnm
gets loaded in between, that causes odd ordering.
"src/core" should not depend on "libnm" and vice versa, so this
should have little effect for now.
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.
phase2-auth applies for EAP-TTLS and EAP-PEAP but the interpretation is
different for one than for the other, clarify the difference.
phase2-auth is for the non-EAP inner methods of EAP-TTLS but is also for
the EAP inner methods of EAP-PEAP. EAP-PEAP doesn't use phase2-autheap
and doesn't support any non-EAP methods.
Given how complicated EAP configuration is it's likely that people just
use example configurations rather than look at the docs. The example
configuration in man/nm-settings-keyfile.xsl is correct in using PEAP
together with phase2-auth=mschapv2.
[thaller@redhat.com: regenerate documentation files]
We redefine G_VARIANT_TYPE() because we don't want to pay a run time
check for what should be a simple cast.
But this is strictly tied to glib, and it must only be done after glib.h
was included. Move it to the right place.
"nm-version-macros.h" is used directly by libnm-core and indirectly by
libnm and core.
Let's not have it randomly under shared/. Move it closer to where it's
used.
Before there was a licensing conflict between the keyfile code
(libnm-keyfile) and libnm. The latter would require LGPL-2.1+ while
keyfile code was GPL-2.0+.
Consequently we were linking libnm-keyfile into the daemon, but not in
libnm.so.
This conflict has been resolved and keyfile API is part of libnm.so.
There is no more need to build a separate (intermediary) library. Merge
them.
This also makes sense because keyfile code needs access to private code
from libnm-core. It is closely tied to libnm-core, so that building them
separate makes no sense (anymore).
"shared/nm-meta-setting.[hc]" contains meta data about settings.
As such it is similarly used by libnm-core (as internal API) and
by clients (as extension of public API of libnm). However, it must
be compiled twice, because while it defines in both cases a
NMMetaSettingInfo type, these types are different between internal and
public API.
Hence, the files must also be compiled twice (and differently), once
against libnm-core and once against the client helper library.
Previously, the file was under "shared/", but there it's a bit odd
it doesn't clearly belong anywhere.
There are two goals here:
- copy the file to the two places where it is used. We also have
a "check-tree" unit test that ensures those files don't diverge in
the future.
- we no longer require CFLAGS set during built. Instead, the sources
should control the build. For that we have new (simple) headers
"nm-meta-setting-base.h" that define the right behavior for the
impl files.
There is still an ugliness (among several): the files must be named the
same for libnm-core and clients/common. Preferably, all our sources have
unique names, but that is not possible with this scheme (without
introducing other ugliness). To mitigate that, include the files only at
one exact place.
"nm-ethtool-utils.h" is part of public API in libnm(-core). It is also
used by shared/nm-base, which must have no dependency on libnm-core.
This was previously solved by symlinking the file. I find that error
prone, because the user might edit one file, without realizing that the
other file also changes.
Instead, copy the file and have it twice. Note that we have a unit test
which checks that both files are (and state) the same.
Copy+paste is a valid way of reusing code. By checking that the copy
does not diverge from the original, the downsides of copy+paste are
mitigated.
Our source tree also has certain consistency requirements. Since the
source is in git, this is a rather static check. However, we want to
ensure that future changes don't break it by adding a test.
autotools projects commonly should include "config.h" as first header.
Also, commonly we need more headers, like glib.h or our nm_auto macros.
Hence, almost all our sources should as first include "nm-default.h".
However, as we build different parts, "nm-default.h" gets controlled
by the NETWORKMANAGER_COMPILATION define which autotools/meson needs
to specify in the build options.
That is confusing.
One advantage of that was, that theoretically the same sources can
be built twice, with different behavior. However, we should avoid doing
that altogether and build static libraries (once) that we link multiple
times.
Another advantage was that if NETWORKMANAGER_COMPILATION is for example
set to build a DAEMON source, there is a check that we don't include
private headers from libnm-core. However, that should be better solved
by not having public, internal and private headers in the same
directory.
Instead, introduce different "nm-default-*.h" headers that don't require
special defines and behave in a consistent way. This way, we require
fewer CFLAGS and it's immediately clear by looking at the source alone
which headers are included. Also, you will be easier see when a wrong
nm-default-*.h header gets included.
Introduce the first replacement. The others will follow.
By now, keyfile code got relicensed as LGPL-2.1+ and is just a regular part
of libnm-core (in particular, because it uses private API of libnm-core).
It should no longer be in a separate directory, but for now, at lead compile
it the same as libnm-core.
Remove the check for NETWORKMANAGER_COMPILATION and NETWORKMANAGER_COMPILATION_TEST
define. We will no longer define that, and the check will be wrong.
We got rid of all these redundant defines. All we need, is the base
source directory, which we already define in config.h as
NM_BUILD_SRCDIR. Use that.
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.
According to RFC3315 section 15.12, Information-request messages can't
include a IA option (such as IA_NA or IA_PD).
When doing stateless DHCPv6, we start the client in the appropriate
mode to issue an Information-request message: with "-S" for dhclient or
calling sd_dhcp6_client_set_information_request(TRUE) for systemd.
However, if we need a prefix later, the client must be restarted to
ask the prefix. Currently both dhclient and systemd clients are still
configured to send an Information-request with prefixes. Fix that.
