`use_carrier` is removed from kernel since 6.18 [1], and returns
the following error if set to 0:
> option obsolete, use_carrier cannot be disabled
This causes a failure of test-link-linux, so let's set it to 1.
[1] https://lore.kernel.org/all/2029487.1756512517@famine/
(cherry picked from commit d40e88fd02)
The formula is wrong for channels above 144 because the layout of the
80MHz channels is not regular. Use a lookup table.
Fixes: 7bb5961779 ('supplicant: honor the 'wifi.channel-width' property in AP mode')
(cherry picked from commit 5763b9b4de)
On a i686 machine the build fails with:
../src/nm-cloud-setup/main.c: In function ‘_oci_new_vlan_dev’:
../src/nm-cloud-setup/main.c:800:47: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘gssize’ {aka ‘int’} [-Werror=format=]
800 | macvlan_name = g_strdup_printf("macvlan%ld", config_data->iface_idx);
| ~~^ ~~~~~~~~~~~~~~~~~~~~~~
| | |
| long int gssize {aka int}
| %d
../src/nm-cloud-setup/main.c:801:42: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘gssize’ {aka ‘int’} [-Werror=format=]
801 | connection_id = g_strdup_printf("%s%ld", connection_type, config_data->iface_idx);
| ~~^ ~~~~~~~~~~~~~~~~~~~~~~
| | |
| long int gssize {aka int}
| %d
Fixes: 68d7e17737 ('Reapply "cloud-setup: create VLANs for multiple VNICs on OCI"')
(cherry picked from commit 748be9a3e7)
Previously, if NM_VERSION_MIN_REQUIRED was not defined, it defaulted to
NM_VERSION. As a consequence, if NM_VERSION_MAX_ALLOWED was defined we
got a compilation error because MAX_ALLOWED < MIN_REQUIRED.
MAX_ALLOWED is used to get compilation warnings if you unintentionally
use a libnm's symbol introduced in a newer version. MIN_REQUIRED is used
to get rid of warnings about symbol deprecations.
Libnm users may want to use MAX_ALLOWED alone, because using a too new
symbol would fail to compile with older libnm. But they might want to
get deprecation warnings as soon as possible, so they want to leave
MIN_REQUIRED empty.
(cherry picked from commit f849163e82)
After the changes in release.sh in previous commits, during development
the value of NM_VERSION will always be the next version, not the latest
released one. As a consequence, we don't need to set MICRO+1 in
NM_API_VERSION, which was a temporary workaround.
(cherry picked from commit 36275bc51c)
After the previous commits, release.sh bumps the version after tagging
the release, and not before. Therefore, it expects that the version is
already the next one when doing the release.
Manually bump the version this time so release.sh sees the right value
the next time it's executed after these changes.
(cherry picked from commit c0fe80ff87)
Fix typo freedestkop -> freedesktop.
Removed unused argument of check_news (additionally, it was incorrectly
using @ instead of $).
Fixed incorrect use of `$? = 0` that was always successful.
(cherry picked from commit 9a3462af99)
After tagging a release, create a commit bumping to the next version.
This effectively ends the change in the logic initiated in the previous
commit, from "bump version, then release" to "release, then bump
version".
The purpose of this is to have the right version set in nm_version.h and
nm_version_macros.h between two releases. Without this change, when we
introduced a new symbol, thus using the NM_AVAILABLE_IN_1_XX annotations,
we got compilation warnings until we did the next release (making the CI
to be red when configured the compilation to fail on warnings).
(cherry picked from commit 5666407f15)
Don't bump the version before tagging the release. Instead, assume that
it's already correctly set. This is in preparation for the next commit
where we will bump the version after the release, not before.
But don't assume that in the case of rc1 and major releases. For rc1 we
switch from devel releases to RC releases, and in major we switch from
RC releases to stable releases. For example, when we are going to
release 1.58-rc1, the current version will be 1.57.X-dev, so we need to
bump to 1.58-rc1. When we're going to release 1.58.0, the current
version will be 1.58-rcX, so we need to bump to 1.58.0.
(cherry picked from commit 3a3a8ea59d)
It's clearer this way, and it will allow to modify directly the
"Version:" and "Release:" fields to bump the version. It is more aligned
with the layout of other projects' spec files too.
(cherry picked from commit 6d952902b9)
Snapshot is only used from nm-copr-build.sh script, so not very useful.
Git_sha is used from build.sh. Other than that, downstream is always
nil.
Remove them and modify build.sh to use --define "dist xxx" instead of
them. This change is motivated by Packit not being able to modify the
release number if it has the %{snap} suffix.
(cherry picked from commit 5445ad2287)
When dist_version is defined in meson, NM installs plugins to a
directory called `NetworkManager-${dist_version}`. If the dist version
contains a `~`, like `1.56~rc1`, defining nmplugindir with
`%{version_no_tilde}` makes it `NetworkManager-1.56-rc1`, causing
rpmbuild errors due to the mismatch.
Fix it by defining nmplugindir with `%{version}` instead.
Fixes: d975389bcd ('spec: use versioning scheme with ~dev and ~rc suffixes')
(cherry picked from commit 9ebc8aa480)
The purpose of the validation is to check that we pass to the
supplicant a configuration that it can understand. For certificates
and keys we enforce a maximum length of 64KiB; that means that the
value of the property we send (i.e. the file path or the blob id) can
be at most 64KiB. Instead we wrongly checked the size of the blob
data.
Fix the validation. Also, enforce a maximum blob size of 32MiB.
Fixes: e85cc46d0b ('core: pass certificates as blobs to supplicant for private connections')
(cherry picked from commit eb784c3f27)
The previous commits has unified the versioning scheme to only use the
version names like 1.56-rc2, 1.56.2 and 1.57.1-dev, like the version
names that we use in the Git tags. The scheme with micro>=90 for RCs
will be used only internally, in the C headers. The tarballs will be
named with the new scheme.
Adapt the release.sh script to correctly understand this versioning
scheme and to create the tarballs with the right new name.
This will enable us to use Packit to automate rpm updates.
(cherry picked from commit 9f4261168d)
In the previous commit meson.build was adapted to use versions with -dev
and -rc suffixes, as we create them in the Git tags, instead of versions
with micro>90 for RCs as we used to do. The tarball name will contain
the version with the new scheme, so adapt the spec file for it.
This will enable us to use Packit to do automatic updates.
(cherry picked from commit d975389bcd)
This will create the tarball with names NetworkManager-1.56-rc2.tar.xz
or NetworkManager-1.57.1-dev.tar.xz. This way they will match with the
name of the Git tag, making easier for users, and specially for tools
like Packit, to understand the versioning scheme.
The goal is to make that there is only one public versioning scheme, the
one with -rc and -dev suffixes. Version numbers with micro>=90 for RC
releases is kept only as an internal thing for the C headers. Users of
the API can still use it.
Bump meson version to 0.56 to use str.substring().
(cherry picked from commit e422b1c3d9)
When connecting to a wifi network and providing the password on the
command line, nmcli first looks if there is a compatible connection to
reuse. If there is not, it creates and activates a new one via a
single call to AddAndActivate().
If there is a compatible connection, nmcli first calls Update() on it
to set the new password and then Activate() to bring it up. Before
that, it registers a secret agent that can prompt for a new password
in case of authentication failure.
However, as soon as nmcli registers a secret agent, NM tries to
activate again the connection if it was blocked due to a previous
authentication failure. This connection attempt is going to fail
because it still uses the old password, as new one hasn't been set via
Update().
Change the order of operations to register the agent after Update()
and before Activate().
Reproducer:
nmcli device wifi connect SSID password BAD_PASSWORD
nmcli device wifi connect SSID password GOOD_PASSWORD
Fixes: c8ff1b30fb ('nmcli/dev: use secret agent for nmcli d [wifi] connect')
(cherry picked from commit 427a7cf257)
Executing this command twice, or when a connection profile already
exists for the SSID:
nmcli device wifi connect $SSID password $PASSWORD
returns error:
Error: 802-11-wireless-security.key-mgmt: property is missing.
When setting the password nmcli was wiping the existing wireless
security setting.
Fixes: c8ff1b30fb ('nmcli/dev: use secret agent for nmcli d [wifi] connect')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1688
(cherry picked from commit 3a4e18e302)
The D-Bus API documentation of the IPv4 and IPv6 settings say:
* addresses
Deprecated in favor of the 'address-data' and 'gateway'
properties, but this can be used for backward-compatibility
with older daemons. Note that if you send this property the
daemon will ignore 'address-data' and 'gateway'.
* gateway
The gateway associated with this configuration. This is only
meaningful if "addresses" is also set.
This documentation wrongly suggests that at D-Bus level "gateway"
requires "addresses", while it actually requires "address-data". The
reason for the inconsistency is that the gateway documentation is
common between nmcli and D-Bus and it refers to the "address" GObject
property, not to the D-Bus property.
Fix this inconsistency by not explicitly mentioning the property name.
Fixes: 36156b70dc ('libnm: Override parts of nm-setting-docs.xml')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2319
(cherry picked from commit dad4da06b1)
The function strerror_r returns an int per POSIX spec, but GNU version
returns char *. Using it fails the compilation in Alpine, so use
_nm_strerror_r instead that handles both cases.
Fixes: 41e28b900f ('daemon-helper: add read-file-as-user')
(cherry picked from commit 599cc1ed1d)
In the past, stable branches used odd micro numbers as development micro
version. Because of that, NM_API_VERSION was defined with MICRO+1 so we
don't get warnings during development.
As we stopped using odd micro=devel it is wrong to set MICRO+1 on odd
releases. Final users of 1.52.3 has NM_API_VERSION 1.52.4.
However, during development we need to have MICRO+1. For example, if we
are working on top of 1.52.3 towards the next 1.52.4, we define new
symbols with NM_AVAILABLE_IN_1_52_4. Because of that, we get compilation
failures until we finally bump to 1.52.4, just before the release. The
CI remains red until then, potentially missing many bugs.
For now, just set MICRO+1 all the time. It is wrong, but it was wrong
half of the time anyway, and at least we'll have a green CI until we
implement a definitive solution.
(cherry picked from commit 13bfa44ceb)
Add a new public function nm_utils_copy_cert_as_user() to libnm. It
reads a certificate or key file on behalf of the given user and writes
it to a directory in /run/NetworkManager. It is useful for VPN plugins
that run as root and need to verify that the user owning the
connection (the one listed in the connection.permissions property) can
access the file.
(cherry picked from commit 1a52bbe7c9)
The new API indicates that the VPN plugin supports reading files
(certificates, keys) of private connections in a safe way
(i.e. checking user permissions), or that it doesn't need to read any
file from disk.
(cherry picked from commit 10db4baeb6)
If we add a new property in the future and it references a certificate
or key stored on disk, we need to also implement the logic to verify
the access to the file for private connections.
Add a new property flag NM_SETTING_PARAM_CERT_KEY_FILE to existing
certificate and key properties, so that it's easier to see that they
need special treatment. Also add some assertions to verify that the
properties with the flag are handled properly.
While at it, move the enumeration of private-files to the settings.
(cherry picked from commit acbfae5e05)
In case of private connections, the device has already read the
certificates and keys content from disk, validating that the owner of
the connection has access to them. Pass those files as blobs to the
supplicant so that it doesn't have to read them again from the
filesystem, creating the opportunity for TOCTOU bugs.
(cherry picked from commit 36ea70c099)
During stage2 (prepare) of an activation, check if the connection is
private and if it contains any certificate/key path. If so, start
reading the files and delay stage2. Once done, store the files'
content into priv->private_files.table and continue the activation.
(cherry picked from commit 98e6dbdf21)
Add function nm_utils_read_private_files(). It can be used to read a
list of paths as the given user. It spawns the daemon-helper to read
each path and returns asynchronously a hash table containing the files
content.
Also add nm_utils_get_connection_private_files_paths() to return a
list of file paths referenced in a connection. The function currently
returns only 802.1x file paths for certificates and keys.
(cherry picked from commit de4eb64253)
The full output of the daemon helper is added to a NMStrBuf, without
interpreting it as a string (that is, without stopping at the first
NUL character).
However, when we retrieve the content from the NMStrBuf we assume it's
a string. This is fine for certain commands that expect a string
output, but it's not for other commands as the read-file-as-user one.
Add a new argument to nm_utils_spawn_helper() to specify whether the
output is binary or not. Also have different finish functions
depending on the return type.
(cherry picked from commit 1d90d50fc6)
When connecting, we add the blobs to the Interface object of the
supplicant. Those blobs are not removed on disconnect and so when we
try to add blobs with the same id, the supplicant returns an error.
Make sure we start from a clean slate on each connection attempt, by
deleting all existing blobs. Probably we should also delete the added
blobs on disconnect, but that's left for a future improvement.
(cherry picked from commit 0093bbd950)
Add a new command to read the content of a file after switching to the
given user. This command can be used to enforce Unix filesystem
permissions when accessing a file on behalf of a user.
(cherry picked from commit 285457a5f8)
Create a new 'nm-helpers' directory for all the helper programs, to
avoid having too many subdirs in the src directory.
(cherry picked from commit 3d76d12eee)
Add utility functions to get the number of users and the first user
from the connection.permissions property of a connection.
(cherry picked from commit 59543620dc)
Restrict connectivity check DNS lookups to just the relevant link if the link
has a per-link DNS resolver configured. This change was previously discussed as
part of issue
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1836, and
brings NM's behavior back in line with the behavior documented in the man page.
The connectivity check checks for a per-link DNS resolver by querying
systemd-resolved's `ScopeMask` for the link; this involves a small D-Bus
roundtrip, but is ultimately the more flexible solution since it is also capable
of dealing with per-link DNS configuration stemming from other sources.
Fixes: e6dac4f0b6 ('core: don't restrict DNS interface when performing connectivity check')
(cherry picked from commit 6e2de1d2b3)
By default, the MPTCP limits have 'add_addr_accepted' set to 0. It means
that when the other peer announces an additional address it can be
reached from, the receiver will not try to establish any new subflows to
this address. If this limit is increased, and without the new 'laminar'
flag, the MPTCP in-kernel path-manager will select the source address by
looking at the routing tables to establish this new subflow.
This is not ideal: very likely, the source address will be the one
linked to the default route and a new subflow from the same interface as
the initial one will be created instead of using another path.
This is especially problematic when the other peer has set the 'C-flag'
in the MPTCP connection request (MP_CAPABLE). This flag can be set to
tell the other side that the peer will not accept extra subflows
requests sent to its initial IP address and port: typically set by a
server using an anycast address, behind a legacy Layer 4 load balancer.
It sounds better to add the 'laminar' flag by default to pick the source
address from well-defined MPTCP endpoints, rather than relying on
routing rules which will likely not pick the most interesting solution.
Note that older kernels will accept unsupported flags, and ignore them.
So it is fine to have the new flag added by default even if it is not
supported.
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
(cherry picked from commit 8caa781270)
