GitLab

(cherry picked from commit c2f7428b)

Fixes: e96051d7 ('libnm: cleanup validating bond option "arp_ip_target"')
(cherry picked from commit 826c83ce)

(cherry picked from commit 5deb7162)

Without this, `nmcli device modify "$DEVICE"` leads to a crash. At least
since commit c5d45848 ('cli: mark argv argument for command line
parsing as const'), when this happens.

That is, because it passes a NULL strv array with argc being set to
zero. nmc_process_connection_properties() is not supposed to access
the array, if there are no elements there.

Fixes: c5d45848 ('cli: mark argv argument for command line parsing as const')

#492
(cherry picked from commit 09c94bc2)

the order of the arguments in the header and C file did not match

Fixes: 69f048bf ('cloud-setup: add tool for automatic IP configuration in cloud')

!574
(cherry picked from commit 16abfca7)

!570

(cherry picked from commit ecba9219)

When configuring miimon settings, the updelay/downdelay fields with
value zero may not be stored in the setting.

For example:

- have a profile with "mode=balance-rr,arp_interval=11,arp_ip_target=10.10.10.1,miimon=10"
  Switch the link monitoring mode to "MII" and press <OK>. Previously,
  the change of the link monitoring did not update the settings, and
  nothing was changed.

- when loading settings, initialize all fields with the values from the
  settings, regardless whether they are currently visible or not.
  Otherwise, if you edit a profile with
  "mode=balance-rr,arp_interval=11,arp_ip_target=10.10.10.1,miimon=10"
  and switch link monitoring mode to "MII", the miimon setting was not
  initialized to 10.

- accept empty bond settings, for example for updelay. In that case,
  initialize the text input to "0". Likewise, when the text entry is
  empty, set the bond option to the respective default.

#488
(cherry picked from commit 61d4bc62)

(cherry picked from commit a0b22b5b)

(cherry picked from commit 211d7998)

Before 1.24, nm_setting_bond_add_option() would clear
miimon/arp_interval settings when the respective other was set.

That was no longer done, with the effect that enabling (for example)
miimon on a bond profile that has arp_interval enabled, sets both
conflicting options.

That is not a severe problem, because the profile still validates.
However, at runtime only one of the settings can be actually configured.

Fix that, by restoring the previous behavior for the client. But note
that this time it's implemented in the client, and not in libnm's
nm_setting_bond_add_option().

(cherry picked from commit b55578bf)

(cherry picked from commit 3a25b3bf)

We use sysfs API for setting bond options. Note that the miimon and
arp_interval settings conflict each other, and whenever setting one
of these sysfs values, the other one gets reset. That means,
NetworkManager needs to mediate and handle a profile which has both
these options set.

Before 1.24, the libnm API nm_setting_bond_add_option() API would mangle
the content of the bond settings, to clear the respective other fields
when setting miimon/arp_interval. That also had the effect that the
settings plugins, weren't able to read such (conflicting) settings
back from disk (but they would write them to disk). If a keyfile
specified both miimon and arp_interval keys, then it would depend on
their order in the keyfile which wins.
It is wrong that a libnm property setter mangles the option in such a way,
especially, because you still could set the NM_SETTING_BOND_OPTIONS
property directly and bypass this. So, since 1.24, you can create
profiles that have conflicting options.

Also, we can now not start to reject such settings as invalid, because that
would be an API break. Instead, just make sure that when one of the
settings is set, that the other one consistently gets deactivated.

Also, before 1.24 already, NMDeviceBond would mediate whether to either set
miimon or arp_interval settings. Despite that the keyfile reader would
mangle the settings, it would also prefer miimon over arp_interval,
if both were set.

This mechanism was broken since we switch to _bond_get_option_normalized()
for that. As a consequence, NetworkManager would try to set both the
conflicting options. Fix that.

(cherry picked from commit 4aa46328)

_bond_get_option_normalized() gets called with code paths that don't
assume a valid options hash. That means, the bond mode might be invalid
and we should fail an assertion.

(cherry picked from commit 1543f8a1)

- the arp_ip_target option in the settings might not have normalized
  IP addresses or duplicates. If there would be duplicates, setting
  them twice would fail with EINVAL. Hence, first normalize them
  and make them unique.

- if what we want to set is identical to what is already set, don't
  do anything.

(cherry picked from commit 6a923a5d)

We already have meta data for all bond options. For example,
"arp_ip_target" has type NM_BOND_OPTION_TYPE_IP.

Also, verify() already calls nm_setting_bond_validate_option() to validate
the option. Doing a second validation below is redundant (and done
inconsistently).

Validate the setting only once.

Also beef up the validation and use nm_utils_bond_option_arp_ip_targets_split()
to parse the IP addresses. This now strips extra whitespace and (as
before) removes empty entries.

(cherry picked from commit e96051d7)

Note yet used. The way how we split the option is relevant at various
places. The code should use the same helper function.

(cherry picked from commit 4ee0e8f0)

(cherry picked from commit f78e0bf2)

https://bugzilla.redhat.com/show_bug.cgi?id=1819587
!457

(cherry picked from commit 6ca98f5b)

SR-IOV parameters are reset when deactivating a connection; do the
same also on failure.

https://bugzilla.redhat.com/show_bug.cgi?id=1819587
(cherry picked from commit 4d6ea18d)

Keep priv->sriov.pending set during the callback set so that it
becomes possible to insert a new operation from the callback itself.

(cherry picked from commit 74ccda8a)

When dispose() is called, there can't be any pending operation because
they keep a reference to the device. Instead, there can be a a queued
operation not yet executed. Destroy it.

(cherry picked from commit 6fcb077a)

The file doesn't exist for all interfaces that support SR-IOV. In
particular, netdevsim devices support SR-IOV but don't expose the
file.

(cherry picked from commit 63a932b8)

When a 'ip=auto6' option is passed to kernel, the old dracut network
module only sets accept_ra in kernel and wait for the address to
appear. Instead, with a 'ip=dhcp6' option it starts 'dhclient -6',
leaving accept_ra to the initial value (that is already 1). So
'ip=dhcp6' in practice does kernel IPv6 autoconf and DHCPv6 at the
same time, without honoring the 'Managed' flag of the router
advertisement.

It seems that the only reason to have distinct 'auto6' and 'dhcp6'
options was that network module did not support starting DHCPv6 only
when necessary based on the M flag of the RA; so the user had to
specify if DHCPv6 was needed or not.

Given that 1) NM is smarter and can start DHCPv6 only when needed by
RA; 2) DHCPv6 alone only gets a /128 address without a prefix route
and so it's not useful; then it makes sense to generate a connection
with 'ipv6.method=auto' for both 'ip=auto6' and 'ip=dhcp6'.

https://bugzilla.redhat.com/show_bug.cgi?id=1854323
!571
(cherry picked from commit ca3d0a8f)

Pre-generate routes in the local table that are configured
by kernel when an ip-address is assigned to an interface.

This helps NM taking into account routes that are not to be deleted
when a connection is reapplied (or deactivated) on an interface instead of only
ignoring (when pruning) IPv6 routes having metric 0 and routes belonging
to the local table having 'kernel' as proto.

https://bugzilla.redhat.com/show_bug.cgi?id=1821787
(cherry picked from commit 3e5fc04d)

@routes are the list of routes we want to configure. This contains
routes from DHCP and manual routes in the profile. It also contains
externally present routes, including the metric=0 routes in the local
table.

Trying to add an IPv6 route with metric zero adds instead a route with
metric 1024.

Usually, we wouldn't do that, because that route was present externally,
so it possibly is still present (in the platform cache) during sync and
we skip the addition. However, there is a race where the external route
might just disappear and we'd add a route with metric 1024.

Avoid that.

(cherry picked from commit a83622f7)

NM will now sync all tables when a connection has specified
at least 1 local route in 'ipv[4|6].routes' to correctly
reconcile local routes when reapplying connections on a device.

If the connection has no local routes only the main table will be
taken into account preserving the previous NM's behaviour.

https://bugzilla.redhat.com/show_bug.cgi?id=1821787
(cherry picked from commit c5496f73)

IPv6 routes having metric 0 and routes having rt_source == kernel
are entirely managed by kernel, NM should not try to remove them.

https://bugzilla.redhat.com/show_bug.cgi?id=1821787
(cherry picked from commit 9ecc27f6)

Pre-generate the device multicast route in the local table that are configured
by kernel when an ipv6-address is assigned to an interface.

This helps NM taking into account routes that are not to be deleted
when a connection is reapplied on an interface.

https://bugzilla.redhat.com/show_bug.cgi?id=1821787
(cherry picked from commit cd89026c)

https://bugzilla.redhat.com/show_bug.cgi?id=1821787
(cherry picked from commit 04878193)

https://bugzilla.redhat.com/show_bug.cgi?id=1821787
(cherry picked from commit e3e7bdf9)

https://bugzilla.redhat.com/show_bug.cgi?id=1821787
(cherry picked from commit d67ad4c8)

NetworkManager can't control the name of the PPP interface name
created by pppd; so it has to wait for the interface to appear and
then rename it. This happens in nm_device_take_over_link() called by
nm-device-ppp.c:ppp_ifindex_set() when pppd tells NM the ifindex of
the interface that was created.

However, sometimes the initial interface name is already correct, for
example when the connection.interface-name is ppp0 and this is the
first PPP interface created.

When this happens, nm_device_update_from_platform_link() is called on
the NMDevicePPP and it sets the device ifindex. Later, when pppd
notifies NM, nm_device_take_over_link() fails because the ifindex is
already set:

 nm_device_take_over_link: assertion 'priv->ifindex <= 0' failed

Make nm_device_take_over_link() more robust to cope with this
situation.

https://bugzilla.redhat.com/show_bug.cgi?id=1849386
(cherry picked from commit 75bc21c4)

Userspace cannot add IPv6 routes with metric 0. Trying to do that, will
be coerced by kernel to route metric 1024. For IPv4 this is different,
and metric zero is commonly allowed.

However, kernel itself can add IPv6 routes with metric zero:

  # ip -6 route show table local
  local fe80::2029:c7ff:fec9:698a dev v proto kernel metric 0 pref medium

That means, we must not treat route metric zero special for most cases.
Only, when we want to add routes (based on user configuration), we must
coerce a route metric of zero to 1024.

!563
(cherry picked from commit 1b408e24)

https://bugzilla.redhat.com/show_bug.cgi?id=1853277
!562
(cherry picked from commit fbac6217)

Don't try to open /run/NetworkManager/initrd when called with
--stdout, but instead write the hostname to the standard output.

Fixes: ff70adf8 ('initrd: save hostname to a file in /run')
(cherry picked from commit 5fa97d77)

There is a bug when parsing a BOOTIF= without any existing
connection. The generated connection doesn't have wired setting and
later we try to access it:

 # nm-initrd-generator --stdout -- BOOTIF=01-50-50-00-9f-21-21
  (nm-initrd-generator:1546): libnm-CRITICAL **: ((libnm-core/nm-setting-wired.c:205)): assertion '<dropped>' failed
  (nm-initrd-generator:1546): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed

Fix this.

https://bugzilla.redhat.com/show_bug.cgi?id=1853277

Fixes: 25a2b6e1 ('initrd: rework command line parsing')
(cherry picked from commit 3023c70e)

Setting a MTU or a cloned MAC for bonds/bridges/teams fails with:

 # nm-initrd-generator -- bond=bond0:eno1,eno2:mode=802.3ad
    ip=192.168.1.5::192.168.1.254:255.255.255.0:MyServer:bond0:none::01:02:03:04:05:06
    bootdev=bond0 nameserver=192.168.1.1

 <warn> cmdline-reader: 'bond' does not support setting cloned-mac-address

Fix this.

#460
(cherry picked from commit 79f70bf5)

https://bugzilla.redhat.com/show_bug.cgi?id=1852106
!557
(cherry picked from commit 15492e6c)

nm_device_cleanup() can be called when the device no longer has an
ifindex. In such case, don't try to reset the MAC address as that
would lead to an assertion failure.

(cherry picked from commit 77b6ce7d)