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.
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
`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/
`argument` is not const, but `tmp` is. We use `tmp`
for reading arguments one by one, but we cannot add
a null byte to separate the key and value if it is const.
Make it non-const, so that `val[0] = '\0';` does not fail.
We write into the buffer returned by nm_strsplit_set_full(), even
though it is returned as `const char**`. The function description
claims this is fine:
> * It is however safe and allowed to modify the individual strings in-place,
> * like "g_strstrip((char *) iter[0])".
Remove the const qualifier via cast so that it does not raise errors.
We reallocate this value in the function, which is necessary
because we write into it, and the input is const.
Move the allocation into a local variable instead of overwriting
the input pointer, because we are also pointing to it via
`char* s`, which is not const.
`subsystem_full` is const, so `s` needs to be const too.
Reorder the NULL-byte write so that we are not writing
into a const char* (the underlying memory is the same).
NetworkManager is failing to build on Rawhide with the following errors:
../src/libnm-systemd-shared/src/basic/string-util.h:33:16: error: return discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
33 | return strstr(haystack, needle);
| ^~~~~~
In file included from ../src/libnm-systemd-shared/src/basic/fd-util.c:30:
../src/libnm-systemd-shared/src/basic/sort-util.h: In function ‘bsearch_safe’:
../src/libnm-systemd-shared/src/basic/sort-util.h:34:16: error: return discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
34 | return bsearch(key, base, nmemb, size, compar);
| ^~~~~~~
This is fixed in systemd by commit 0bac1ed2422f15308414dd1e9d09812a966b0348:
> Latest glibc uses _Generic to have strstr() and other functions return
> const char* or char* based on whether the input is a const char* or a
> char*. This causes build failures as we previously always expected a char*.
>
> Let's fix the compilation failures and add our own macros similar to glibc's
> to have string functions that return a mutable or const pointer depending on
> the input.
Selectively backport the changes we need to fix building.
It has been deprecated for a long time, so it would be probably
fine to stop building with it enabled. RHEL 9 is excluded since
it still supports the ifcfg-rh format.
The NetworkManager.conf man page is describing some options as
"whether X is enabled", without explicitly saying that it's a
boolean. Also, the allowed values are not mentioned. Clarify those
aspects.
Since both `NetworkManager.service` and `NetworkManager-initrd.service` are
allocated for the same bus name (`org.freedesktop.NetworkManager`) and this is
not allowed, the best option is to use a systemd generator to install them only
in the initrd, instead of setting fixed Install sections.
Fixes#1814
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')
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>
This new endpoint type has been recently added to the kernel in v6.18
[1]. It will be used to create new subflows from the associated address
to additional addresses announced by the other peer. This will be done
if allowed by the MPTCP limits, and if the associated address is not
already being used by another subflow from the same MPTCP connection.
Note that the fullmesh flag takes precedence over the laminar one.
Without any of these two flags, the path-manager will create new
subflows to additional addresses announced by the other peer by
selecting the source address from the routing tables, which is harder to
configure if the announced address is not known in advance.
The support of the new flag is easy: simply by declaring a new flag for
NM, and adding it in the related helpers and existing checks looking at
the different MPTCP endpoint. The documentation now references the new
endpoint type.
Note that only the new 'define' has been added in the Linux header file:
this file has changed a bit since the last sync, now split in two files.
Only this new line is needed, so the minimum has been modified here.
Link: https://git.kernel.org/torvalds/c/539f6b9de39e [1]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
It's possible that the first timeout gets delayed; therefore the
interval between the first and the second callback can be less than
one second, and the budget doesn't refill completely.
Schedule the second timeout from the first callback to guarantee that
at least one second passes between the callbacks.
Fixes: ff0c4346fc ('core: add rate-limiting helper')
Sending and receiving RA is repeated periodically. Don't spam logs
with the same message again and again. Rate limit the message to 6
every 12 hours per type and per ndisc instance.
Using nm_device_create_l3_config_data_from_connection in favor of
nm_l3_config_data_new_from_connection allows the connection
properties: connection.mdns, connection.llmnr,
connection.dns-over-tls, connection.dnssec, connection.mptcp-flags,
and ipv6.ip6-privacy to be read from the vpn's connection settings
allowing them to be applied to vpn connections.
Currently nm_device_create_l3_config_data_from_connection uses the
connection applied to the given device for some properties. Altough
this currently works since all users of
nm_device_create_l3_config_data_from_connection provide the applied
connection as parameter, it behaves unexpectedly when another
connection is given.
Fix the rule that triggers this job so it is run each time that a commit
is pushed/merged to main. The incorrect rule was doing that it only ran
when the *source* branch (or a MR) was called "main". Therefore, it was
(almost) never running.
Fixes: 69efb4660c ('CI: periodically clean image's registry')
This is needed to ensure that the right CleanupType is chosen when
calling to nm_device_state_changed() a bit later. With this change
CLEANUP_TYPE_REMOVED will be used instead of CLEANUP_TYPE_DECONFIGURE,
which is wrong because the device has already disappeared.
As we introduced the ipv4.forwarding property in a8a2e6d727 ('ip-config:
Support configuring per-device IPv4 sysctl forwarding option'), we must
not enable or disable the global forwarding setting in the kernel, as it
affects to all the devices, maybe forcing them to behave in a way
different to what the user requested in ipv4.forwarding.
Instead, we need to selectively enable or disable the per-device forwarding
settings. Specifically, only devices activated with ipv4.forwarding=auto
must have their forwarding enabled or disabled depending on shared
connections. Devices with yes/no must not be affected by shared connections.
Also, devices with ipv4.forwarding=auto must get the proper forwarding value
on activation, but also change it when shared connections appear or
disappear dynamically. Use the new sharing-ipv4-change signal from
nm_manager to achieve it.
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
