GCC 14 with LTO complains with:
In function 'nm_team_link_watcher_new_ethtool',
inlined from 'nm_team_link_watcher_new_ethtool' at src/libnm-core-impl/nm-setting-team.c:106:1:
src/libnm-core-impl/nm-setting-team.c:130:33: error: array subscript 'struct NMTeamLinkWatcher[0]' is partly outside array bounds of 'unsigned char[16]' [-Werror=array-bounds=]
130 | watcher->ref_count = 1;
| ^
src/libnm-core-impl/nm-setting-team.c:128:15: note: object of size 16 allocated by 'g_malloc'
128 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool));
| ^
even if the warning is disabled via pragma directives in that
code. This looks like the following GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
saying
We do not track warning options (and thus optimize pragmas /
attributes) across LTO because they are not saved in the function
specific optimization flag section.
We use a (NMTeamLinkWatcher *) to point to a memory area that is
shorter than the struct, because depending on the watcher type we need
to store different parameters; in this way we can save few bytes of
memory for some watcher types. However, this often breaks when
upgrading the compiler; instead just allocate the full struct.
GCC 14 complans with:
src/libnm-glib-aux/nm-uuid.c: In function 'nm_uuid_generate_from_strings_strv':
src/libnm-glib-aux/nm-uuid.c:492:12: error: '_1' may be used uninitialized [-Werror=maybe-uninitialized]
492 | 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,
| ^
"-Wmaybe-uninitialized" diagnoses passing pointers or references to
uninitialized memory to functions taking const-qualified arguments.
In this case, nm_uuid_generate_from_string_str()'s first argument is a
"const char *" and so the compiler expects that the string is always
initialized. However, it is not initialized when len is zero.
A non-null zero-length array can be specified in two ways: by setting
len to zero, or by setting len to -1 and having NULL as first
element. Handle both cases in the same way.
NMPowerMonitor emits the "shutdown" signal without arguments; fix the
definition of the signal.
Fixes: bd38a19832 ('connection: add support to down-on-poweroff')
Fix the following:
NetworkManager: file ../src/libnm-core-impl/nm-connection.c: line 321 (nm_connection_get_setting): should not be reached
NetworkManager.service: Main process exited, code=dumped, status=5/TRAP
Fixes: bd38a19832 ('connection: add support to down-on-poweroff')
Meson has shared_library and shared_module. The latter should be used
only for shared plugins loaded by dlopen, not for shared libraries
linked by the linker.
The target `nm_wwan` was defined as shared_module probably because it
is a library for loadable plugins only, andcontains references to
symbols from the main executable that cannot be resolved at link time.
Do as the deprecation message suggest and convert it to shared_library
with b_lundef=false:
DEPRECATION: target nm-device-plugin-wwan links against shared module nm-wwan, which is incorrect.
This will be an error in the future, so please use shared_library() for nm-wwan instead.
If shared_module() was used for nm-wwan because it has references to undefined symbols,
use shared_library() with `override_options: ['b_lundef=false']` instead.
Replaced by full_path:
https://mesonbuild.com/Reference-manual_returned_external_program.html#external_programpath
ExternalProgram.full_path was added in meson 0.55 but we support meson
>= 0.51. Because of that, use path or full_path conditionally depending
on the meson version.
This gets rid of the following deprecation warning:
NOTICE: Future-deprecated features used:
* 0.48.0: {'module python3'}
* 0.55.0: {'ExternalProgram.path'}
Instead, meson.current_source_root or meson.project_source_root should
be used:
https://mesonbuild.com/Reference-manual_builtin_meson.html#mesonsource_root
Also, the documentation referenced above suggest to use `files()` as a
better alternative to refer to files, so do that at the same time.
This gets rid of the deprecation warning:
NOTICE: Future-deprecated features used:
* 0.56.0: {'meson.source_root'}
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
