We now always use SetLinkDefaultRoute(), but that API was only added in
systemd v240 ([1]).
We could just always call the non-existing method, and ignore the
error. However, that feels ugly. Would systemd-resolved log warnings
about that? Should we suppress all messages about that failure (not
good for debugging).
Instead, make an effort to detect support of the function, and avoid
calling it. That is significantly more complicated than just always
calling the method and not care.
Note that even if systemd-resolved does not support SetLinkDefaultRoute(),
we cannot do anything smart about that. We would simply rely on
systemd-resolved (hopefully) doing the right thing automatically.
That's better and simpler than explicitly adding a "~." domain in
the fallback case.
Also, detecting support is straight forward in the common case, where
there is either success or a clear "org.freedesktop.DBus.Error.UnknownMethod"
error. In cases where there is any other failure, we don't really know.
In that case, we keep trying to use the API under the assumption that
it should work.
[1] https://github.com/systemd/systemd/commit/7 ## 7673795dcf5797491e7f785cbf5077d29a15db4
(cherry picked from commit 44ebb99cfa)
When the DNS settings change, we update the request_queue_lst_head list,
with all the requests we want to send.
Then, send_updates() will try to send it. It might not do it right away,
if resolved is not on the bus or the D-Bus connection is not fully inialized
(meaning, we don't know the name owner yet). In those cases, we would
keep the list of requests, and send them later.
However, when sending them, we would also forget about the configuration.
That means, if you restart systemd-resolved, then the daemon drops off
the bus and reappears. I think that systemd-resolved in fact persists
the configuration during restart. So, usually the settings are still the
same after restart. However, we should do better here: if the service
appears, we should send the settings again.
This means to not forget the requests after we send them once -- at
least, until a new update replaces them.
(cherry picked from commit 4fc44952f7)
We will need these changes next:
- add "self" and "ifindex" fields to RequestItem struct. We will
pass on these structs are user-data for the callbacks, so that
we afterwards know which request completed.
- add DBUS_OP_SET_LINK_DEFAULT_ROUTE global variable. We don't
clone the "operation" string but use string literals. However,
string literals are not guaranteed to be deduplicated, so we
should only compare them with strcmp(). The static variable
avoids this: we can use pointer equality to compare it.
This will be used next.
(cherry picked from commit 8af6647cda)
We now always use SetLinkDefaultRoute(), but that API was only added in
systemd v240 ([1]).
We could just always call the non-existing method, and ignore the
error. However, that feels ugly. Would systemd-resolved log warnings
about that? Should we suppress all messages about that failure (not
good for debugging).
Instead, make an effort to detect support of the function, and avoid
calling it. That is significantly more complicated than just always
calling the method and not care.
Note that even if systemd-resolved does not support SetLinkDefaultRoute(),
we cannot do anything smart about that. We would simply rely on
systemd-resolved (hopefully) doing the right thing automatically.
That's better and simpler than explicitly adding a "~." domain in
the fallback case.
Also, detecting support is straight forward in the common case, where
there is either success or a clear "org.freedesktop.DBus.Error.UnknownMethod"
error. In cases where there is any other failure, we don't really know.
In that case, we keep trying to use the API under the assumption that
it should work.
[1] https://github.com/systemd/systemd/commit/7 ## 7673795dcf5797491e7f785cbf5077d29a15db4
When the DNS settings change, we update the request_queue_lst_head list,
with all the requests we want to send.
Then, send_updates() will try to send it. It might not do it right away,
if resolved is not on the bus or the D-Bus connection is not fully inialized
(meaning, we don't know the name owner yet). In those cases, we would
keep the list of requests, and send them later.
However, when sending them, we would also forget about the configuration.
That means, if you restart systemd-resolved, then the daemon drops off
the bus and reappears. I think that systemd-resolved in fact persists
the configuration during restart. So, usually the settings are still the
same after restart. However, we should do better here: if the service
appears, we should send the settings again.
This means to not forget the requests after we send them once -- at
least, until a new update replaces them.
We will need these changes next:
- add "self" and "ifindex" fields to RequestItem struct. We will
pass on these structs are user-data for the callbacks, so that
we afterwards know which request completed.
- add DBUS_OP_SET_LINK_DEFAULT_ROUTE global variable. We don't
clone the "operation" string but use string literals. However,
string literals are not guaranteed to be deduplicated, so we
should only compare them with strcmp(). The static variable
avoids this: we can use pointer equality to compare it.
This will be used next.
NetworkManager is now able to configure veth interfaces throught the
NMSettingVeth. Veth interfaces only have "peer" property.
In order to support Veth interfaces in NetworkManager the design need
to pass the following requirements:
* Veth setting only has "peer" attribute.
* Ethernet profiles must be applicable to Veth interfaces.
* When creating a veth interface, the peer will be managed by
NetworkManager but will not have a profile.
* Veth connection can reapply only if the peer has not been modified.
* In order to modify the veth peer, NetworkManager must deactivate the
connection and create a new one with peer modified.
In general, it should support the basis of veth interfaces but without
breaking any existing feature or use case. The users that are using veth
interfaces as ethernet should not notice anything changed unless they
specified the veth peer setting.
Creating a Veth interface in NetworkManager is useful even without the
support for namespaces for some use cases, e.g "connecting one side of
the veth to an OVS bridge and the other side to a Linux bridge" this is
done when using OVN kubernetes [1][2]. In addition, it would provide
persistent configuration and rollback support for Veth interfaces.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
NMDeviceEthernet will be used to support Veth interfaces. Therefore, it
needs to be defined on libnm/nm-libnm-utils.h
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
We always run the unit tests during package build and also enable all compiler
warnings. However, by default we used to ignore failures. That is, because
rebuilding a package on another, future distro led to frequent, annoying build
failures. Especially compiler warnings appear easily when using a
different compiler version.
The default mostly matters here when you want to build the package in
brew/koji, where you don't have a possibility to explicitly select the
build option.
Note that rpmdiff detects failures in the build log, and thus we usually
would not miss failures for builds we add to errata. Also, all our CI
tests build packages with a manner where they would not allow a failure
of the unit tests. So, we run these unit tests frequently and in a
manner where we notice a failure.
For rhel-9 builds, change the default here and let test failures and
compiler warnings be fatal to the build.
If the same MAC address is set on both the bridge connection and the
interface connection, and the interface is local, NM currently sets
the hwaddr record in both Bridge and Interface ovsdb tables. As a
result, ovs complains with error:
bridge|ERR|interface br0: ignoring mac in Interface record (use Bridge record to set local port's mac)
Avoid this error: if the bridge and interface MACs are the same, just
set the address in the Bridge table; if they are different, give a
more detailed warning and ignore the interface MAC.
https://bugzilla.redhat.com/show_bug.cgi?id=1899745
(cherry picked from commit c4beaac67b)
The parser checks if the first token of an ip= argument is an IP
address to determine which of the two possible syntaxes is used:
ip=<interface>:{dhcp|on|any|dhcp6|auto6}[:[<mtu>][:<macaddr>]]
ip=<client-IP>:[<peer>]:<gateway-IP>:<netmask>:<client_hostname>:<interface>:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[<mtu>][:<macaddr>]]
This works as long as the first token is not empty, which - according
to the dracut.cmdline man page - seems to be guaranteed.
However, the network-legacy dracut plugin accepts an empty interface
or client IP. Also, if a user needs DHCP and wants to specify a
hostname, the only possible syntax is:
ip=::::<hostname>::dhcp
Change the parser to check the second token instead, similarly to what
the network-legacy module does [1].
[1] https://github.com/dracutdevs/dracut/blob/050/modules.d/40network/net-lib.sh#L490https://bugzilla.redhat.com/show_bug.cgi?id=1900260https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/693
(cherry picked from commit b0c018830e)
If the same MAC address is set on both the bridge connection and the
interface connection, and the interface is local, NM currently sets
the hwaddr record in both Bridge and Interface ovsdb tables. As a
result, ovs complains with error:
bridge|ERR|interface br0: ignoring mac in Interface record (use Bridge record to set local port's mac)
Avoid this error: if the bridge and interface MACs are the same, just
set the address in the Bridge table; if they are different, give a
more detailed warning and ignore the interface MAC.
https://bugzilla.redhat.com/show_bug.cgi?id=1899745
The parser checks if the first token of an ip= argument is an IP
address to determine which of the two possible syntaxes is used:
ip=<interface>:{dhcp|on|any|dhcp6|auto6}[:[<mtu>][:<macaddr>]]
ip=<client-IP>:[<peer>]:<gateway-IP>:<netmask>:<client_hostname>:<interface>:{none|off|dhcp|on|any|dhcp6|auto6|ibft}[:[<mtu>][:<macaddr>]]
This works as long as the first token is not empty, which - according
to the dracut.cmdline man page - seems to be guaranteed.
However, the network-legacy dracut plugin accepts an empty interface
or client IP. Also, if a user needs DHCP and wants to specify a
hostname, the only possible syntax is:
ip=::::<hostname>::dhcp
Change the parser to check the second token instead, similarly to what
the network-legacy module does [1].
[1] https://github.com/dracutdevs/dracut/blob/050/modules.d/40network/net-lib.sh#L490https://bugzilla.redhat.com/show_bug.cgi?id=1900260https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/693
If the interface is the DNS default route but has no domain, its name
servers were not sent to systemd-resolved. Fix this.
Fixes: ee9fab0361 ('dns: fix handling default routing domains with systemd-resolved')
(cherry picked from commit 195cbf3cee)
If the interface is the DNS default route but has no domain, its name
servers were not sent to systemd-resolved. Fix this.
Fixes: ee9fab0361 ('dns: fix handling default routing domains with systemd-resolved')
"find-backports" searches commit messages of upstream branches for
"Fixes:" comments. Those will then be highlighted to be backported,
if the script determines that to be necessary.
"find-backports" also honors the "cherry picked from" comments, to detect when
a patch was already backported. That is thus a way to suppress reporting a
commit to be backported.
Add another way to flag commits so they don't need backporting. Via
"Ignore-Backport:" tag.
As "find-backports" also honors "refs/notes/bugs" notes, this can be used
like:
git notes \
--ref refs/notes/bugs \
append \
-m "Ignore-Backport: e""29f00fa0c69 ('NEWS: fix entry that is targeted for 1.30 instead of 1.28')" \
2''3364aa8f3bd6b11e2ac9e30117eaabfe1f3a9f2
Change the generator to disable by default IP configuration for the
parent connection of a VLAN, because that is what a user would expect
and what the legacy module does. Of course if the user explicitly
configures DHCP or an address for the parent interface, that overrides
the default.
Note that now the generator always creates a connection for the parent
interface. Before this commit, it did only when there was an explicit
ip= argument for the parent interface.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/509
(cherry picked from commit f2e51ace68)
The command line parser looks for a dot or a colon to determine
whether the first token in a ip= argument is a IPv4 address (dot), an
IPv6 address (colon) or an interface name (none). This strategy
doesn't work for interface names containing a dot (typically VLANs).
Instead, try to parse the IPv4/IPv6 address in the token; if this
fails then consider the token as an interface name.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/581
(cherry picked from commit 4aa902ecf5)
This is potentially a breaking change, formerly speciyfing 'none|off'
in the kernel cmdline option 'ip' was understood by the dracut
network-module as doing 'ipv6.method=auto' which is clearly incosistent
with the 'off' naming, thus 'off|none' now means to actually disable
both ipv6 and ipv4 (unless a static ip is provided).
Unit test added.
https://bugzilla.redhat.com/show_bug.cgi?id=1883958
Reverts: 440a0b4078 ('initrd: set ipv6.method=auto when the autoconfiguration field is 'none'')
Signed-off-by: Antonio Cardace <acardace@redhat.com>
(cherry picked from commit fc7c83cbdd)
Let's try to rework and improve the implementation.
The code is already rather complicated from the start. Let's first try
to use consistent names for things. Naming is very important, so that
they follow a pattern that tells you what something does.
We will rework preparing the DNS data, so that we do things that
currently "nm-dns-systemd-resolved.c" does (see InterfaceConfig).
We thus will need to access the NMDnsConfigData, which is per-ifindex.
As such, it is useful to have NMDnsConfigData in a stable order, sorted
by ifindex. As we track NMDnsConfigData in a hash table, we need to
do the sorting outside of that.
There are many ways to achive that. The solution here is to let
NMDnsConfigData also be tracked by a CList. We only need to resort
the list, when we add a new ifindex -- which should happen only seldom.
The advantage is that the sorting happens in-place and can expose
it to other uses (by providing them access to the CList head).
"NM_IP_CONFIG_GET_CLASS(config)->is_ipv4" only follows a pointer (except
additional assertions in debug builds). It's thus more efficient than
NM_IS_IP4_CONFIG(), which needs to compare GType and call
nm_ip4_config_get_type().
Let's add a nm_utils_get_reverse_dns_domains_ip() function, which can
operate on both address families. We frequently do that, but then our
address family specific functions tend to have an underscore in the name.
Rename.
