Replaced by 'python' module:
https://mesonbuild.com/Python-3-module.html.
This get rids of the following deprecation warning:
NOTICE: Future-deprecated features used:
* 0.48.0: {'module python3'}
We were already using some features from 0.49:
WARNING: Project specifies a minimum meson_version '>= 0.47.2' but uses features which were added in newer versions:
* 0.48.0: {'meson.add_dist_script'}
* 0.49.0: {'Calling "add_dist_script" with multiple arguments'}
Debian 10 uses meson 0.49.2, but it will get out of support in 2 months
so we can start considering it as a too old version. Next oldest meson
version used by the distros that we follow is Ubuntu 20.04 with meson
0.53.2.
Raise to 0.51 as it is supported by all the distros that we test (except
Debian 10) and it contains all the features that we need for the next
commits.
The test "tarball+meson" fails on systems with old meson version with
the message "ERROR: Neither directory contains a build file
meson.build". This message is raised when calling `meson dist` from the
build directory.
According to meson documentation, `meson dist` is supported since 0.52,
and older vesions need to execute `ninja dist`.
https://mesonbuild.com/Creating-releases.html
Also, when using meson.add_dist_script, the env variable MESON_SOURCE_ROOT
is not passed in versions < 0.54. As we don't use it in the script,
don't assert for it.
We claim to support down to meson 0.47.3 (we need to raise it because we
are actually using a bit newer features, but that's another topic). Use
`ninja dist` that will work fine on old and new meson.
Fixes: 61f0531509 ('gitlab-ci: test re-buildability of distribution tarballs')
We want to distribute the generated documentation when we generate the
tarball because we normally do it when we do a release, but `meson dist`
only includes files that are commited to the repository, so a script
meson-dist-data.sh was added with meson.add_dist_script in commit
1c41066a40 ('build: include documentation in meson dist').
This script was copying the whole documentation folders, including some
intermediate files that are not useful for users that wants to read the
docs. Get rid of them and copy only the files that are useful for users:
the generated html pages in docs/api and docs/libnm and the final man
pages.
Also, including these intermediate files caused at least one build
failure, although quite difficult to reproduce:
- Generate tarball with meson
- Untar the generated tarball
- Using the sources from the tarball, configure the project with
autotools, but building to an out-of-tree folder, not building in
the source dir (i.e. using a 'build' subfolder). This is called
a "VPATH build" by autotools and Make. See:
- https://www.gnu.org/software/make/manual/html_node/General-Search.html
- https://www.gnu.org/software/automake/manual/html_node/VPATH-Builds.html
- Build
In that scenario, we get an error trying to generate any file under man/
because the man/ subdirectory has not been created. The reason of this
was that the man/ subdirectory is created by the Makefile when
generating the file man/common.ent. However, this file was present in
the source directory because it has been included in the tarball, so
Make detects it and doesn't run the rules to generate it. The result is
that out-of-tree-dir/man folder is not created.
Not including the intermediate files solves this problem.
Fixes: 1c41066a40 ('build: include documentation in meson dist')
Command NL80211_CMD_GET_WIPHY without any flag only returns channels
in the 2 GHz and 5 GHz bands, for backwards compatibility with old
userspace tools. To get the full list we need to pass attribute
NL80211_ATTR_SPLIT_WIPHY_DUMP (added in Linux 3.9 released in 2013),
and allow the handler to be called multiple times.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1500
When creating the socket for listening to LLDP frames we are setting
NM_ETHERTYPE_LLDP (0x88cc) as protocol. In most of the cases, that is
correct but when the interface is attached as a port to a OVS bridge,
kernel is not matching the protocol correctly. The reason might be that
some metadata is added to the packet, but we are not completely sure
about it.
Instead, we should use ETH_P_ALL to match all the protocols. Later, we
have a eBPF filter to drop the packet by multicast MAC address or
protocol. This is how lldpd is doing it for example.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1903
In Fedora 40+, we have complaining failure:
```
src/libnm-glib-aux/nm-uuid.c: In function 'nm_uuid_generate_from_strings_strv':
src/libnm-glib-aux/nm-uuid.c:490:12: error: '_1' may be used
uninitialized [-Werror=maybe-uninitialized]
490 | return nm_uuid_generate_from_string_str(s, slen, uuid_type,
type_args);
| ^
src/libnm-glib-aux/nm-uuid.c:392:1: note: by argument 1 of type 'const
char *' to 'nm_uuid_generate_from_string_str' declared here
392 | nm_uuid_generate_from_string_str(const char *s,
| ^
lto1: all warnings being treated as errors
lto-wrapper: fatal error: gcc returned 1 exit status
```
Fixed by set the `s` initial variable to NULL;
Signed-off-by: Gris Ge <fge@redhat.com>
Configuring the build directory with meson often fails if you don't have
the right Qt dependencies. As they are used only to build some examples,
it is better to autodetect them and, if present, then build the
examples but skip them otherwise.
Still accept forcing qt=true or qt=false as before.
Note that there is a option type called "feature" whose purpose is to
support exactly this: features with enable/disable/auto possible values:
https://mesonbuild.com/Build-options.html#features. However, they don't
accept true/false values so scripts using qt=true/false would start
failing. Since meson 0.60 the "deprecated" argument can be used for
options (https://mesonbuild.com/Build-options.html#deprecated-options),
but that's a too new version of meson.
Also, this fixes some Gitlab-CI failures that happen when generating the
tarball with make distcheck or meson dist. This is because it tries to
check that the tarball content can be configured and built, but it uses
the default configurations so it was using qt=yes. Now it will use
qt=auto, avoiding the failure.
Fixes: 61f0531509 ('gitlab-ci: test re-buildability of distribution tarballs')
The value can be unknown for different reasons:
- we don't have a value saved in NMDevice's "ip6_saved_properties"
because NM was restarted or because the device didn't have an
ifindex when it became managed.
- the value read from /proc is outside the allowed range (kernel
allows "echo 42 > /proc/sys/net/ipv6/conf/enp1s0/use_tempaddr")
Note that the second case was already possible before commit
797f3cafee ('device: fall back to saved use_tempaddr value instead
of rereading /proc').
If we can't determine the previous value, pass "unknown" to ndisc; it
will generate a l3cd with "unknown" ip6-privacy, which means to not
set the value when committing the configuration.
Fixes: 797f3cafee ('device: fall back to saved use_tempaddr value instead of rereading /proc')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1907
While enumerating devices at startup, we take a snapshot of existing
links from platform and we start creating device instances for
them. It's possible that in the meantime, while processing netlink
events in platform_link_added(), a link gets renamed. If that happens,
then we have two different views of the same ifindex: the cached link
from `links` and the link in platform.
This can cause issues: in platform_link_added() we create the device
with the cached name; then in NMDevice's constructor(), we look up
from platform the ifindex for the given name. Because of the rename,
this lookup can match a newly created, different link.
The end result is that the ifindex from the initial snapshot doesn't
get a NMDevice and is not handled by NetworkManager.
Fix this problem by fetching the latest version of the link from
platform to make sure we have a consistent view of the state.
https://issues.redhat.com/browse/RHEL-25808https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1897
When IPv6 privacy extensions are enabled, by default temporary addresses
have a valid lifetime of 1 week and a preferred lifetime of 1 day.
That's far too long for privacy-conscious users, some of whom want a new
address once every few seconds. Add connection options that correspond
to /proc/sys/net/ipv6/conf/*/temp_valid_lft and
/proc/sys/net/ipv6/conf/*/temp_prefered_lft to allow configuring the
address rotation time on a per-connection basis.
The new properties are defined as 32-bit signed integers to match the
sysctl parameters which are also signed, although currently only
positive numbers are valid.
Fixes the following deprecation warning:
meson.build:585: DEPRECATION: configuration_data.set10
with number. the `set10` method should only be used with booleans
This replaces the underlying type of mac_address_blacklist, which is currently GArray,
with a more re-usable NMValueStrv, which allows us to implement it as a direct property.
The comparison checking for MAC address equality had previously been flipped around.
Fixes: b084ad7f2b ('libnm-core: canonicalize hardware addresses in settings')
A common source for doubts and questions from users is about why
devices are unmanaged. Unfortunately NM doesn't expose that
information properly via D-Bus and so it's not available in nmcli.
The device D-Bus object has two properties that are strictly related:
"state" and "state-reason". The latter represents the reason for the
current state. Introduce new reasons to indicate the possible causes
for the unmanaged state. Note that a device can be unmanaged because
of multiple reasons at the same time, we only return one.
Before:
$ nmcli -f GENERAL.DEVICE,GENERAL.TYPE,GENERAL.STATE,GENERAL.reason device show
GENERAL.DEVICE: enp7s0
GENERAL.TYPE: ethernet
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 0 (No reason given)
GENERAL.DEVICE: tun0
GENERAL.TYPE: tun
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 0 (No reason given)
GENERAL.DEVICE: hwsim0
GENERAL.TYPE: unknown
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 0 (No reason given)
After:
$ nmcli -f GENERAL.DEVICE,GENERAL.TYPE,GENERAL.STATE,GENERAL.reason device show
GENERAL.DEVICE: enp7s0
GENERAL.TYPE: ethernet
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 76 (The device is unmanaged by user decision via settings plugin ("unmanaged-devices" for keyfile or "NM_CONTROLLED=no" for ifcfg-rh))
GENERAL.DEVICE: tun0
GENERAL.TYPE: tun
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 75 (The device is unmanaged by explicit user decision (e.g. 'nmcli device set $DEV managed no')
GENERAL.DEVICE: hwsim0
GENERAL.TYPE: unknown
GENERAL.STATE: 10 (unmanaged)
GENERAL.REASON: 69 (The device is unmanaged because the device type is unmanaged by default)
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1887
'stdout' is NULL when the script didn't write anything or failed.
Fixes the following crash detected by NMCI in test
'dispatcher_device_handler_dummy'.
nm-dispatcher[936339]: g_strsplit: assertion 'string != NULL' failed
build_result_options (nm-dispatcher)
complete_request (nm-dispatcher)
complete_script (nm-dispatcher)
script_watch_cb (nm-dispatcher)
g_child_watch_dispatch (libglib-2.0.so.0)
g_main_dispatch (libglib-2.0.so.0)
g_main_context_iterate (libglib-2.0.so.0)
g_main_context_iteration (libglib-2.0.so.0)
main (nm-dispatcher)
__libc_start_main (libc.so.6)
_start (nm-dispatcher)
Fixes: d72f26b875 ('dispatcher: read device-handler's stdout into a dictionary')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1889
Allow user to edit openssl_strings and phase1_auth_flags using nmtui.
Hide these settings behind "Show expert TLS options" checkbox when
edited network uses default values for these options.
Setting for wpa_supplicant openssl_ciphers - openssl sometimes moves
ciphers among SECLEVELs. That is generaly a good thing, but some servers
are too old to support newer ciphers. Thus expert user should be allowed
to define openssl_ciphers per connection, so that they can connect to
old server, while not compromising security of other connections.
When creating VLAN over OVS internal interface which holding the same
name as its controller OVS bridge, NetworkManager will fail with error:
Error: Connection activation failed: br0.101 failed to create
resources: cannot retrieve ifindex of interface br0 (Open vSwitch
Bridge)
Expanded the `find_device_by_iface()` with additional argument
`child: NmConnection *` which will validate whether candidate is
suitable to be parent device.
In `nm_device_check_parent_connection_compatible()`, we only not allow OVS
bridge and OVS port being parent.
Resolves: https://issues.redhat.com/browse/RHEL-26753
Signed-off-by: Gris Ge <fge@redhat.com>
Fixes the following warning:
src/libnm-client-impl/meson.build:139: WARNING: Keyword argument "header" defined multiple times.
WARNING: This will be an error in future Meson releases.
With `NM_CHECKPOINT_CREATE_FLAG_TRACK_INTERNAL_GLOBAL_DNS` flag set on
checkpoint creation, the checkpoint rollback will restore the
global DNS in internal configure file
`/var/lib/NetworkManager/NetworkManager-intern.conf`.
If user has set global DNS in /etc folder, this flag will not take any
effect.
Resolves: https://issues.redhat.com/browse/RHEL-23446
Signed-off-by: Gris Ge <fge@redhat.com>