In the scenario for sending the release message, we need to guarantee
that NM only sends the release message when the client received a lease
from the server. However, there is some distinction between the
`l3cd_curr` and `l3cd_next` when ACD is pending, because `l3cd_curr` is
NULL but `l3cd_next` is not NULL when ACD is pending. Regardless of
whether ACD is pending or completed, these are all considered the client
have received the release from the server. Therefore, adapt the function
`nm_dhcp_client_get_lease()` to control whether to get next or current
lease.
Now "fedpkg prep" command is generating a directory with the "-build"
suffix containing the build directory inside. We need to extract it.
Real example:
If the script is used for a branch related to nm-1-46, the "fedpkg prep"
command will generate a NetworkManager-1.46-build/ directory containing
the NetworkManager-1.46/ sources directory. We just need to move the
NetworkManager-1.46/ out.
In the "Action()" D-Bus method, the "nameservers" key used to contain
an array of binary addresses. If we change the key to contain
something else, there can be problems when the NM and the
NM-dispatcher versions mismatch (right after an upgrade or a
downgrade).
To avoid such problem, still send the old key in the old format, and
introduce a new key for the new format. The new format carries the
name servers as a string list, and can encode encrypted DNS servers.
Introduce a new kernel command line option named "rd.net.dns" that can
be used to specify a global name server. It accepts name server in a
URI-like form, as for example:
rd.net.dns=dns+tls://[fd01::1]:5353#mydomain.com
Accept name servers specified with an URI syntax in the global
configuration. A plugin that doesn't support a specific scheme can
decide to ignore it and use only the servers it understands. At the
moment there is no plugin that supports DNS-over-TLS servers in the
global configuration.
Introduce new functions to parse and normalize name servers. Their
name contains "dns_uri" because they also support a URI-like syntax
as: "dns+tls://192.0.2.0:553#example.org".
Remove unused "server_name" argument. It is still possible to pass the
server name, if needed, with the nm_l3_config_data_add_nameserver()
function. After this change, rename the function to
nm_l3_config_data_add_nameserver_addr(), since the function only
accepts an address.
We only add to Tier 3 distro versions that ship a version of NM equal or
older to the one that we are testing. As CentOS Stream uses "main", no
stable version will be tested on it.
Force to test CentOS Stream as Tier 3.
The regex for "Fixes" also matches with "Ignore-Fixes", so the commit is
added twice and then removed only once by the "Ignore-Fixes". It still
remains once in the list of commits to backport, making that
"Ignore-Fixes" does not work. Fix it.
Now we are using scheduled pipelines for various purposes like
regenerating the container images and triage the issues and MRs. That
means that the last pipeline ran for main might not be the pipeline with
the jobs building and testing the code.
Use `source=push` to retrieve only pipelines that are not scheduled.
The help text is read from the comments at the top of the script itself.
However, to detect what lines belongs to the help text, a range was
defined as:
- Start: any line starting with `# `
- End: any line starting `# Run with --no-test`
If any later line starts with `# ` is considered as a new matching
range, and from it to the end of the file is printed too.
Fix it by defining the range:
- Start: line 2
- End: blank line
GNOME has changed the process to publish releases to download.gnome.org.
Now, it is required to do it from the CI of projects hosted in GNOME's
repositories.
As we don't have the project hosted there, we have 2 options:
- Create a mirror and set up the CI so we continue using
download.gnome.org.
- Stop publishing the tarballs there and do it in gitlab.freedesktop.org
from now on.
After a brief discussion we have decided that the second makes more
sense, so adapt release.sh to do that.
https://discourse.gnome.org/t/gnome-release-service-ftpadmin-replacement-coming-11th-december/25487https://handbook.gnome.org/maintainers/making-a-release.html
When a bond in balance-slb is created, the ports are enabled or disabled
based on carrier and link state. If the link/carrier goes down, the port
becomes disabled and we must make sure the MAC tables of the switches
are updated properly so the traffic is redirected.
In order to solve this, we send a GARP or RARP broadcast packet on the
bond. This fix cover 3 different balance-slb scenarios.
Scenario 1: The bond in balance-slb mode has IPv4 address configured and
some ports connected. Here the bond is acting like active-backup as the
packets will always have as source MAC the address of the bond
interface. When a port goes down, NetworkManager will send a GARP
broadcast announcing the address configured on the bond with the MAC
address configured on the port.
Scenario 2: The bond in balance-slb mode is connected to a bridge and has
some ports connected. The bridge has IPv4 configured. When a port goes
down, NetworkManager will send a GARP broadcast announcing the address
configured on the bridge with the MAC address configured on the port.
Scenario 3: The bond in balance-slb mode is connected to a bridge and
has some ports connected. The bridge does not have IP configuration and
therefore everything is L2. When a port goes down, NetworkManager will
query the FDB table and filter the entries by the ones belonging to the
bridge and the bond ifindexes. Then, it will send a RARP broadcast
announcing every learned MAC address from FDB.
Fixes: e9268e3924 ('firewall: add mlag firewall utils for multi chassis link aggregation (MLAG) for bonding-slb')
The function introduced queries the FDB table via netlink socket. It
accepts a list of ifindexes to filter out the FDB content not related to
it. It returns an array of MAC addresses.
To cltarify this function is unusually exposed directly on
nm-linux-platform.h as we don't want this be part of the whole
NMPlatform object or cache. This, is an exception to the rule to
simplify the integration of this functionality on NetworkManager.
In addition, it also doesn't use the async mechanism that is widely used
on netlink communication across nm-linux-platform. Again, the reason is
to simplify its use, as async communication won't provide a benefit to
the use cases we have planned for this, i.e balance-slb RARP announcing.
This function would be useful when performing operations related to the
IPv4 addresses configured on the l3cfg. E.g this function will be used
for getting the IPv4 to announce on a GARP on bonding-slb when one of
the ports failover.
In the original addition of the ModemManager backend for mobile
broadband, IPv6 was set to be disabled/ignored by default. The original
motivation for this is not obvious, but it should be gone after 11
years. Some carriers have IPv6-only networks for which the default
IPv4-only connection attempt is inappropriate. Enable IPv6 by default to
support more WWAN networks without special configuration.
Changing the default does not affect IPv4-only support thanks to
fallbacks implemented in nm_modem_get_connection_ip_type().
Link: https://gitlab.com/postmarketOS/pmaports/-/issues/2752
Fixes: a9032724cb ('modem-manager: new `NMModemBroadband'')
Previously, NM create direct route to gateway to main(254) route table
regardless `ipvx.route-table` value.
Fixed by setting `NMPlatformIP4Route.table_any` to `TRUE`.
Resolves: https://issues.redhat.com/browse/RHEL-69901
Signed-off-by: Gris Ge <fge@redhat.com>
We always sync routes in the main table, but routes in tables other
than main are only pruned if were added by NM, by default. Get the list
of routes to prune from other tables using obj_state->os_nm_configured,
as this tracks what routes were effectively added by NM.
The list should be the same that the one obtained from l3cfg_old. It
could be different if we commited the l3cfg with an NMIPRouteTableSyncMode
of NM_IP_ROUTE_TABLE_SYNC_MODE_MAIN, thus not deleting some routes at
commit time. However, since the previous commit, we never do it.
What all this shows is that starting to use different NMIPRouteTableSyncModes
is probably a bad idea: it will be a source of bugs of routes not being
always synced as users expect, and the use case for them is still to be
known.
By default, on reapply we were only syncing the main routes table. This
causes that routes added by NM to other tables are not removed on
reapply. This was done to preserve routes added externally, but routes
added by NM itself should be removed.
Add a new route table syncing mode "main + NM routes". This mode
maintains the normal behaviour of syncing completely the main table,
and for other tables removes only routes that were added by us, leaving
the rest untouched. Use this mode by default, as this is what a user
would expect on reapply.
Note: this might not work if NM is restarted between the profile being
modified and the reapply, because NM forgets what routes were added by
itself because of the restart. This is a rare corner case, though.
Use the D-Bus property "VersionInfo" to expose a capability flag
indicating that this bug is fixed. It is the first capability that we
expose in this way. However, it is convenient to do it this way as it's
something that clients like nmstate needs to know, so they can decide
whether a conn down is needed or not. It is not enough to decide that by
version number because it might be fixed via a downstream patch in distros
like RHEL.
https://issues.redhat.com/browse/RHEL-67324https://issues.redhat.com/browse/RHEL-66262
Fixes: e9c17fcc9b ('l3cfg: default to 'main' route table sync mode')
The difference between FULL and ALL was not obvious without reading the
documentation. Moreover, a new mode is going to be introduced so the
confusion could grow. Rename to a more explicit name.
Remove the `+ 31u` that was making that it would search for bit 1 at
array's element 1, instead of element 0. Fixed comparison >len that
shoudl be >=len. Fix a few typos.
Fixes: bc6098d441 ('libnm: add internal nmc_client_has_{version_info_v,version_info_capability,capability}() helper')
when the kernel boot parameter ipv6.disable=1 is set, NetworkManager
attempts to read files under /proc/sys/net/ipv6, resulting in numerous
error messages in the debug logs. For example:
NetworkManager[758]: <debug> [1726699000.9384] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/disable_ipv6: Failed to open file "/proc/sys/net/ipv6/conf/lo/disable_ipv6": No such file or directory
NetworkManager[758]: <debug> [1726699000.9400] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/accept_ra: Failed to open file "/proc/sys/net/ipv6/conf/lo/accept_ra": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/disable_ipv6: Failed to open file "/proc/sys/net/ipv6/conf/lo/disable_ipv6": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/hop_limit: Failed to open file "/proc/sys/net/ipv6/conf/lo/hop_limit": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/use_tempaddr: Failed to open file "/proc/sys/net/ipv6/conf/lo/use_tempaddr": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/temp_valid_lft: Failed to open file "/proc/sys/net/ipv6/conf/lo/temp_valid_lft": No such file or directory
NetworkManager[758]: <debug> [1726699000.9401] platform-linux: error reading /proc/sys/net/ipv6/conf/lo/temp_prefered_lft: Failed to open file "/proc/sys/net/ipv6/conf/lo/temp_prefered_lft": No such file or directory
...
This also results unnecessary system calls by attempting to open non-existent sysfs.
This patch adds checks in some ipv6 sysctl functions to verify the existence of /proc/sys/net/ipv6.
While there are still other paths that attempts to open IPv6 sysfs, this
eliminates many reading errors.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2040
RFC 4191 section-3.1 says:
When processing a Router Advertisement, a type C host first updates a
::/0 route based on the Router Lifetime and Default Router Preference
in the Router Advertisement message header. [...] The Router Preference
and Lifetime values in a ::/0 Route Information Option override the
preference and lifetime values in the Router Advertisement header.
Fix the RA parsing so that the parameters from a default route option
are applied to the gateway.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1666https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2072
Fixes: c3a4656a68 ('rdisc: libndp implementation')
The keyfile format allows to specify the gateway in two ways: with a
separate "gateway" key, or by appending the gateway address to one of
the address$N lines:
[ipv4]
address1=192.0.2.1/24
gateway=192.0.2.254
[ipv4]
address1=192.0.2.1/24,192.0.2.254
The former syntax is self-documenting and easier to understand for
users, but NetworkManager defaults to the latter when writing
connection files, for historical reasons. Change that and use the
explicit form.
Note that if a users has scripts manually parsing keyfiles, they could
stop working and so this can be considered an API breakage. OTOH,
those scripts are buggy if they don't support both forms, and they can
already break with perfectly valid user-generated keyfiles.
I think it's acceptable to change the default way to persist keyfiles;
the only precaution would be that this patch should not be applied
during a stable release cycle of a distro.
We already check that a connection doesn't not change when it's
written and re-read from disk. Add another check to verify that the
generated keyfile matches a static one, so that we don't introduce
unwanted changes. The reference keyfiles can be generated by running
the test with "NM_TEST_REGENERATE=1".
