With accept_ra set to 1, kernel sends its own router solicitation
messages and parses the advertisements. This duplicates what NM
already does in userspace and has unwanted consequences like [1] and
[2].
The only reason why accept_ra was re-enabled in the past was to apply
RA parameters like ReachableTime and RetransTimer [3]; but now NM
supports them and so accept_ra can be turned off again.
Also, note that previously the option was set in
addrconf6_start_with_link_ready(), and so this was done only when the
method was 'auto'. Instead, now we clear it for all methods except
'ignore'.
[1] https://mail.gnome.org/archives/networkmanager-list/2019-June/msg00027.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1734470
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1068673
(cherry picked from commit 5a534529e2)
IPv6 router advertisement messages contain the following parameters
(RFC 4861):
- Reachable time: 32-bit unsigned integer. The time, in
milliseconds, that a node assumes a neighbor is reachable after
having received a reachability confirmation. Used by the Neighbor
Unreachability Detection algorithm. A value of zero means
unspecified (by this router).
- Retrans Timer: 32-bit unsigned integer. The time, in milliseconds,
between retransmitted Neighbor Solicitation messages. Used by
address resolution and the Neighbor Unreachability Detection
algorithm. A value of zero means unspecified (by this router).
Currently NM ignores them; however, since it leaves accept_ra=1, the
kernel parses RAs and applies those parameters for us [1].
In the next commit kernel handling of RAs will be disabled, so let NM
set those neighbor-related parameters.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/ndisc.c?h=v5.2#n1353
(cherry picked from commit 5f0c6f8d3b)
We try to set only one time the MTU from the connection to not
interfere with manual user changes.
If at some point the parent interface changes temporarily MTU to a
lower value (for example, because the connection was reactivated), the
kernel will also lower the MTU on child interface and we will not
update it ever again.
Add a workaround to this. If we detect that the MTU we want to set
from connection is higher that the allowed one, go into a state where
we follow the parent MTU until it is possible to set again the desired
MTU. This is a bit ugly, but I can't think of any nicer way to do it.
https://bugzilla.redhat.com/show_bug.cgi?id=1751079
(cherry picked from commit ec28f5b343)
A MACsec connection doesn't have an ordering dependency with its
parent connection and so it's possible that the parent gets activated
later and sets a greater MTU than the original one.
It is reasonable and useful to keep the MACsec MTU configured by
default as the maximum allowed by the parent interface, that is the
parent MTU minus the encapsulation overhead (32). The user can of
course override this by setting an explicit value in the
connection. We already do something similar for VLANs.
https://bugzilla.redhat.com/show_bug.cgi?id=1723690
(cherry picked from commit 438a0a9ad5)
Introduce a generic function to set a MTU based on parent's one. Also
define a device-specific @mtu_parent_delta value that specifies the
difference from parent MTU that should be set by default. For VLAN it
is zero but other interface types (for example MACsec) require a
positive value due to encapsulation overhead.
(cherry picked from commit 5cf57f4522)
NMDeviceVxlan has some "q" type properties. They were not handled:
$ G_MESSAGES_DEBUG=all PAGER= LIBNM_GLIB_DEBUG=properties-changed nmcli 2>&1 | grep "couldn't be set from D-Bus type"
libnm-Message: 10:44:04.538: demarshal_generic: NMDeviceVxlan:dst-port (type guint) couldn't be set from D-Bus type q.
libnm-Message: 10:44:04.538: demarshal_generic: NMDeviceVxlan:src-port-max (type guint) couldn't be set from D-Bus type q.
libnm-Message: 10:44:04.538: demarshal_generic: NMDeviceVxlan:src-port-min (type guint) couldn't be set from D-Bus type q.
libnm-Message: 10:44:04.539: demarshal_generic: NMDeviceWireGuard:listen-port (type guint) couldn't be set from D-Bus type q.
(cherry picked from commit e2dac63de6)
In nm_acd_manager_announce_addresses() we should not only start the
probes but also add the acd file descriptor to the main loop.
Otherwise, a timer is armed to send the announcements but it never
fires and no announcements are sent.
Fixes: d9a4b59c18 ('acd: adapt NM code and build options')
https://bugzilla.redhat.com/show_bug.cgi?id=1767681
(cherry picked from commit 14992ab9cd)
If the 802.1X authentication fails and 802-1x.optional is set,
continue with activation. In this case, subscribe to the auth-state
supplicant property so that any dynamic IP method can be restarted
when the authentication succeeds. This is because upon authentication
the switch could have changed the VLAN we are connected to.
(cherry picked from commit 8afce75bf3)
Introduce a 802-1x.optional boolean property that can be used to
succeed the connection even after an authentication timeout or
failure.
(cherry picked from commit 8763e6da9c)
property_to_dbus() returns NULL when called with
NM_CONNECTION_SERIALIZE_WITH_SECRETS_AGENT_OWNED and the property is
not an agent-owned secrets. The function doesn't handle VPN secrets
correctly, since they are all stored as a hash in the vpn.secrets
property and the flag for each of them is a matching '*-flags' key in
the vpn.data property. VPN secrets must be handled differently; do it
in the VPN setting to_dbus_fcn() function.
Fixes: 71928a3e5c ('settings: avoid cloning the connection to maintain agent-owned secrets')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/230https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/280
(cherry picked from commit 43b7e66948)
Handle rd.znet with legacy interface names too, the index for eth or ctc
corresponds to the position on the command line.
(cherry picked from commit 22e388d90e)
When processing the rd.znet option set the interface name only in case when
the persistent interface names feature isn't disabled via net.ifnames=0
[lkundrak@v3.sk: minor tweaks to the net.ifnames=0 parsing]
(cherry picked from commit c7423dca89)
The current solution for s390 specific details relies on an interface to
exist before adding the s390 details. It means the ip= option must precede
the rd.znet= option. Also only a single interface can be configured. With
this change the s390 details are put to the right interface and properly
named interface is created if it hasn't existed yet.
(cherry picked from commit adcc52c3da)
The upstream apparently thought it's a great idea to change the agent
manager path. This fixes things for those unfortunate enough to run
IWD.
(cherry picked from commit 186d22a963)
Since commit 159ff23268 ('dhcp/dhclient-utils: skip over
dhclient.conf blocks') we skip blocks enclosed in lines containing '{'
and '}' because NM should ignore 'lease', 'alias' and other
declarations. However, conditional statements seem useful and should
not be skipped.
https://bugzilla.redhat.com/show_bug.cgi?id=1758550
(cherry picked from commit b58e4d311d)
PMF can be used with SAE, allow it. Actually, it is required according
to WPA3 specifications but there are implementations that don't
require it (hostapd can be configured in a such way); so let's not
make it mandatory for WPA3.
Fixes: 6640fb4b36 ('supplicant: add support for SAE key management')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/257
(cherry picked from commit e36c297fd8)
The Bluetooth DUN device's NMModem would signal the reset of ifindex to zero
when it's disconnected and the NMDeviceBt would accordingly update the
bluetooth device's ip ifindex. This is not okay since commit ab4578302d
('device: refactor nm_device_set_ip_ifindex() and set_ip_iface()') which,
although claiming to be a refactoring, made such use of
nm_device_set_ip_ifindex() illegal. Resetting the ifindex is anyway not
necessary, since it's taken care of _cleanup_generic_post().
Let's leave the ifindex alone once the device is activated, in a manner
analogous to what NMDeviceModem.
Fixes: ab4578302d ('device: refactor nm_device_set_ip_ifindex() and set_ip_iface()')
Fixes: 78ca2a70c7 ('device: don't set invalid ip-iface'):
(cherry picked from commit a5ca504b5b)
Otherwise, the script tries to run
dbus-run-session -- exec ...
which fails (because `exec` is a shell command, not a program).
After the failure, the code falls through to run the test under
valgrind.
Fixes: 6a58c55ca4 ('run-nm-test: Just use exec instead of running and exiting')
(cherry picked from commit b9c4d2bb72)
When a test is going to be run under valgrind we set NM_TEST_UNDER_VALGRIND
so that we can properly check whether this is happening.
(cherry picked from commit 073eda68fc)
When opening a merge request from a fork of NetworkManager, then the
pipeline runs with the a checkout of the fork. That means, checkpatch
would compare the branch against "master" (or "nm-x-y" stable branches)
of the fork, instead of upstream.
That doesn't seem too useful. Instead, also add upstream NetworkManager
as git remote, fetch the branches, and use the branches from there as
base for checkpatch.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/255
(cherry picked from commit 3019648b4b)
"ubuntu:devel" ships iproute2 version "5.2.0-1ubuntu1". This has a well known
bug that prevents it from creating IP tunnels during the unit tests.
We already workaround that on Debian. Add the same workaround to match the
Ubuntu package.
(cherry picked from commit 44193d3def)
