`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)
Print some statistics about the translation when the connection goes
down:
clat: stats: egress (v4 to v6): tcp 1275, udp 191, icmp 9, other 0, dropped 2; ingress (v6 to v4): tcp 1669, udp 272, icmp 0, other 0, fragment 136, dropped 0
Those counters can be used to better understand what's going wrong in
case of problems; for example, if the packets are being dropped in the
ingress path or in the egress one.
When running the CLAT over an interface that doesn't use the Ethernet
header, like an IP tunnel, there are some changes needed. The BPF
program must compute offsets differently. Also, the DAD packet should
not include an Ethernet header.
libndp >= 1.9 is only required to parse the PREF64 option needed for
CLAT. When building NM in an enviroment with an older libndp, still
allow building without CLAT support.
It is useful to show that the CLAT is enabled and which addresses and
prefix it is using. Add this information to the overview and to the
device/connection output. Example:
$ nmcli
veth0: connected to clat
"veth0"
ethernet (veth), 4A:37:01:56:9D:AE, sw, mtu 1500
ip4 default
inet4 192.0.0.5/32
route4 default metric 101
inet6 2002:aaaa::64d4:2932:3585:7c89/64
inet6 fe80::c060:8caf:f69b:e41a/64
route6 fe80::/64 metric 1024
route6 2002:aaaa::/64 metric 101
route6 default via fe80::871:7ff:fe14:b7b9 metric 101
clat inet4 192.0.0.5 inet6 2002:aaaa::2c0d:1e71:ef87:fac7 pref64 64:ff9b::/96
$ nmcli connection show clat
...
IP4.ADDRESS[1]: 192.0.0.5/32
IP4.GATEWAY: 0.0.0.0
IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 0.0.0.0, mt = 101
IP4.CLAT-ADDRESS: 192.0.0.5
IP6.ADDRESS[1]: 2002:aaaa::64d4:2932:3585:7c89/64
IP6.ADDRESS[2]: fe80::c060:8caf:f69b:e41a/64
IP6.GATEWAY: fe80::871:7ff:fe14:b7b9
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 1024
IP6.ROUTE[2]: dst = 2002:aaaa::/64, nh = ::, mt = 101
IP6.ROUTE[3]: dst = ::/0, nh = fe80::871:7ff:fe14:b7b9, mt = 101
IP6.CLAT-ADDRESS: 2002:aaaa::2c0d:1e71:ef87:fac7
IP6.CLAT-PREF64: 64:ff9b::/96
Note how the IPv4 CLAT address is displayed both in IP4.ADDRESS and
IP4.CLAT-ADDRESS. That's because it is also configured in kernel. The
IPv6 CLAT address is not displayed in IP6.ADDRESS because it's not
configured in kernel.
In the l3cd we already stored the CLAT administrative state (whether
we want to enable it or not) and the selected PREF64. Also store the
other current CLAT parameters, so that we can export them to clients
via D-Bus.
As per draft-ietf-v6ops-claton-14, hosts must perform duplicate
addresses detection (DAD) on the generated CLAT IPv6 address. This is
necessary not only to avoid address collisions but also because some
networks drop traffic from addresses that have not done DAD.
Since doing true DAD adds complexity, adopt the same approach as
Android: start DAD by sending a neighbor solicitation and don't wait
for any reply. This avoids the problem with dropped traffic; it
doesn't help with collisions, but collisions are anyway very unlikely
because the interface identifier is a random 64-bit value.
5ae193ae36/clatd/main.c (363)
Previously the NMNDisc instance always used the last received NAT64
prefix. If a network advertises multiple NAT64 prefixes,
NetworkManager would constantly flip between them. Change this and
keep a list of valid PREF64. Most importantly, stick with the same
PREF64 unless a new one appears from a router with higher priority, or
the current PREF64 expires.
A property should be hidden when it has the default value and one of the
following conditions is met:
- nmcli is called in "overview" mode (with flag -o)
- the property has the HIDE flag
Previously, properties with the HIDE flag were always hidden. Fix
that.
Remove the mentioned limitation of limiting authentication retires to
802.1X connections and add information about the introduced secret
prompting behaviour.
While NetworkManager tries it's best to determine whether a new PSK is
needed, it can still run into edge cases. One of these edge cases is that
a device can leave the range of an access point and therefore fail a 4-way
handshake. Because these cases can't be confidently detected, a device
which was previously connected, should try to exhaust it's authentication
retries before requesting new secrets. This leads to less user-facing
prompts while increasing the time from PSK change to prompt.
Devices don't know whether they have authentication retries left,
so they can only make decisions ad-hoc after calling
nm_device_auth_retries_try_next.
Giving devices a way to determine whether the current attempt is their
last attempt, allows them to make decisions before failing a connection.
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.
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.
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.
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.
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).
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.
Previously the metric of the CLAT default route was set to the IPv6
route metric plus 50. Instead:
- If there is another non-CLAT default route on the device, use the
same metric plus 1, so that native connectivity is always
preferred.
- Otherwise, use the metric from the "ipv4.route-metric" property of
the connection profile.
There is no guarantee that the part of the packet we want to read or
write via direct packet access is linear. From the documentation of
bpf_skb_pull_data():
For direct packet access, testing that offsets to access are within
packet boundaries (test on skb->data_end) is susceptible to fail if
offsets are invalid, or if the requested data is in non-linear parts
of the skb. On failure the program can just bail out, or in the case
of a non-linear buffer, use a helper to make the data available. The
bpf_skb_load_bytes() helper is a first solution to access the
data. Another one consists in using bpf_skb_pull_data to pull in
once the non-linear parts, then retesting and eventually access the
data.
See: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2107#note_3288979
Reported-by: DasSkelett <dasskelett@dasskelett.dev>
Avoid the additional function call and perform the needed checks
directly in clat_handle_v4() and clat_handle_v6(). It will make easier
to check that the packet is linear is the next commit.
Convert IPv6 fragments into IPv4.
The PLAT fragments IPv4 packets larger than the IPv6 MTU size into
smaller IPv6 packets. The safest IPv6 MTU value to configure on a PLAT
is the minimum IPv6 MTU, 1280. Therefore, we can expect IPv6 fragments
to be quite common.
