When using the netdev datapath, we wait that the tun link appears, we
call nm_device_set_ip_ifindex() (which also brings the link up) and
then we check that the link is ready, i.e. that udev has announced the
link and the MAC address is correct. After that, we schedule stage3
(ip-config).
In this, there is a race condition that occurs sometimes in NMCI test
ovs_datapath_type_netdev_with_cloned_mac. In rare conditions,
nm_device_set_ip_ifindex() bring the interface up but then ovs-vswitch
changes again the flags of the interface without IFF_UP. The result is
that the interface stays down, breaking communications.
To fix this, we need to always call nm_device_bring_up() after the tun
device is ready. The problem is that we can't do it in
_netdev_tun_link_cb() because that function is already invoked
synchronously from platform code.
Instead, simplify the handling of the netdev datapath. Every
"link-changed" event from platform is handled by
_netdev_tun_link_cb(), which always schedule a delayed function
_netdev_tun_link_cb_in_idle(). This function just assigns the
ip-ifindex to the device if missing, and starts stage3 if the link is
ready. While doing so, it also bring the interface up.
Fixes: 99a6c6eda6 ('ovs, dpdk: fix creating ovs-interface when the ovs-bridge is netdev')
https://issues.redhat.com/browse/RHEL-17358https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2218
When connecting to an AP configured for WPA3 transition mode, the
connection will fail if PMF is disabled on the client due to SAE and
FT-SAE being unconditionally added to the key_mgmt variable's
parameters.
By removing the "!is_ap ||" check, SAE and FT-SAE will no longer be
selected when PMF is disabled, allowing clients to connect via
WPA2/PSK mode as per the original intent of
a0988868ba.
Signed-off-by: Conn O'Griofa <connogriofa@gmail.com>
- ausearch is part of audit package
- mlocate is not available anymore
- "openvswitch2*" packages are not available anymore
- ipsec-tools is not available anymore
It appears that xsltproc is not installed there. It is generally needed
for the docs build too, so as a crude CI heuristic, don't build anywhere
that docs are disabled.
Currently, both man pages and gtk-doc HTML documentation are enabled by
the same build option. It is common for users to want to choose whether
to build HTML docs, as not everyone cares about HTML developer docs, but
manpages are intended directly for end-user consumption and should
always be available. At the very least, there should be a separate
option to disable them to avoid accidentally disabling them while trying
to disable HTML developer docs.
Resolves: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1653
When building from a release tarball of NetworkManager,
`meson.add_dist_script()` has copied various prebuilt manpages into the
tarball and building them again is not really necessary. We can just
install those directly.
This means that *all* manpages could be installed even without
introspection, even though some of them can only be *built* when
introspection is enabled.
It also means that manpages can be installed even when xsltproc is not
available at build time.
This was likely added during the port to meson. It's just a multiline
string, so it has no effect in meson, and it appears to be entirely for
things which are already implemented in meson, so there's no real point
in keeping it any longer.
It's intrinsically used when building manpages, and also part of the
introspection-specific parts of the documentation build. There's no
particular guarantee either of those will actually be invoked during a
build, so don't unconditionally look it up.
This allows building with one fewer dependency in many cases.
The Open VSwitch interfaces have corresponding platform links. When an
Open VSwitch interface is created while NetworkManager is running, the
OVS factory usually sees an OVSDB entry appear first, then creates a
NMDevice. After that, when a platform link appears, the device is
already there.
Upon a (re-)start, the link might be seen first, and then things
go south. The OVS factory rejects the device, which results in Generic
device being created instead. Another device, this time of an
appropriate is created for the same link once the OVSDB entry is seen.
Needless to say, with two NMDevices for the same platform link existing,
no end of mayhem ensues (an assertion is tripped).
Resolves: https://issues.redhat.com/browse/NMT-1634https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2207
A device has the "external-down" unmanaged flag when:
!is-created-by-nm AND (!is-up OR (!has-address AND !is-controller))
When the "is-up" or the "has-address" conditions change, we properly update
the unmanaged flag by calling _dev_unmanaged_check_external_down() in
_dev_l3_cfg_notify_cb(PLATFORM_CHANGE_ON_IDLE).
The "is-controller" condition changes when another link indicates the
current device as controller. We currently don't update the unmanaged flag
when that happens and so it's possible that the device stays unmanaged even
if it has a port. This can be easily reproduced by running this commands:
ip link add veth0 type veth peer name veth1
ip link add vrf0 type vrf table 10
ip link set vrf0 up
ip link set veth0 master vrf0
Sometimes, the device shows as "unmanaged" instead of "connected
(externally)".
Fix this by re-evaluating the "external-down" unmanaged flags on the
controller when a port is attached or detached.
Fixes: c3586ce01a ('device: consider a device with slaves configured')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2209
When calling to nm_device_is_available, the device types that requires a
parent like VLAN or MACVLAN checks that their parent exists.
nm_device_is_available is a function to check if the device is available
to activate a connection, so it makes sense that if the parent is not
present it can't be activated.
However, this is wrong for 2 reasons:
1. Most of they are virtual devices that might be unrealized when
checking its availability. If they're unrealized, their parent hasn't
been set yet.
2. Even if they're realized, their current parent might not be the one
that is defined in the connection that is being activated.
This is causing that unrealized devices are not being activated as ports
because nm_manager_get_best_device_for_connection thinks that they are
not available.
Get rid of these checks for the parent in the is_available callbacks.
Fixes: ba86c208e0 ('Revert "core: prevent the activation of unavailable OVS interfaces only"')
Fixes: 774badb151 ('core: prevent the activation of unavailable devices')
When defining an IPv6 address with square brackets and prefix, like
[dead::beef]/64, the prefix was silently ignored. The address was
accepted only accidentally, because get_word replaced ']' with '\0' so
it resulted in a valid IPv6 address string, but without the prefix.
The previous commit has fixed get_word with better logic to handle the
square brackets, uncovering this issue.
Fix it by explicitly splitting IP addresses and prefixes in
reader_parse_ip so we get a valid address and prefix.
Also, use a prefix different to 64 in the test test_if_ip6_manual. 64 is
the default one, making that the test passed despite the defined prefix
was actually ignored.
Fixes: ecc074b2f8 ('initrd: add command line parser')
If any bond option contains an IPv6 address it needs to be enclosed with
[]. Otherwise the ':' separators from the IP address can be confused
with the ':' separators from the 'bond=' cmdline arguments.
However, the square brackets were ignored:
$ nm-initrd-generator -s "bond=bond0:eth0,eth1:ns_ip6_target=[FC08::789:1:0:0:3]"
NetworkManager-Message: 08:46:55.114: <warn> [1745498815.1146] cmdline-reader: Ignoring invalid bond option: "ns_ip6_target" = "[FC08": '[FC08' is not a valid IPv6 address for 'ns_ip6_target' option
NetworkManager-Message: 08:46:55.114: <warn> [1745498815.1148] cmdline-reader: Ignoring extra: '789:1:0:0:3]'.
The opening '[' was only being considered if it was the first character
in `get_word`. Fix it and consider it if it's in the middle too.
If the brackets are used first and last, directly remove them as it is what
most callers expect. However, if it's in the middle there is no reasonable
way to remove them, so don't do it. Instead, the caller will have to consider
this possibility when processing the content.
Fixes: ecc074b2f8 ('initrd: add command line parser')
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1755
NMDevices have a special "can_reapply_change_ovs_external_ids" boolean
field indicating whether the device type supports reapplying the
ovs-external-ids and ovs-other-config settings.
Remove this field and use the standard can_reapply_change() method. No
change in behavior is expected.
If a OVS bridge created via NM has a port created externally, when the
bridge connections goes down then NM detaches the NM-created
port. However, it finds that the bridge still has a port (the external
one) and so it doesn't remove the bridge from ovsdb.
This is a problem, because it means that an explicity deactivation of
the bridge leaves the bridge up. To fix this, only track the number of
port in the bridge actually created by NM. Also, leave alone bridges
not created by NM.
