The systemd DHCPv6 client requires a hardware address only to
determine the IAID; NM always overrides the IAID with its own and
therefore the hwaddr is not used.
Removing such requirement allows DHCPv6 to run over PPP, which is
useful with DHCPv6-PD to get a prefix from the ISP.
To test this, I set up a server with pppoe-server, radvd and the Wide
DHCPv6 server providing an address and a prefix. On the client, NM was
able to obtain a prefix using both dhcp=dhclient and dhcp=systemd.
Note that if there is no hardware address and you specify
ipv6.dhcp-duid=ll or ipv6.dhcp-iaid=mac, a warning will be emitted and
NM will use a random DUID/IAID.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/478
(cherry picked from commit 76a6a30577)
(cherry picked from commit 905d4eb36e)
If IPv6 is disabled, changing the IPv6 MTU fails and NM complains with
a warning. Since this error is expected and doesn't do any harm,
downgrade the logging level to DEBUG.
Since IPv6 kernel support can be built as a module, we have to check
the existence of /proc/sys/net/ipv6 every time. Instead of checking it
and then setting the MTU (adding one /proc access for everyone), just try
to set the MTU; in case of failure, determine the reason for the error.
https://bugzilla.redhat.com/show_bug.cgi?id=1840989https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/585
(cherry picked from commit 9c09dcedaf)
(cherry picked from commit ce3dffd24e)
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 77b6ce7d04)
(cherry picked from commit 791a888cad)
We already set the MAC of OVS interfaces in the ovsdb. Unfortunately,
vswitchd doesn't create the interface with the given MAC from the
beginning, but first creates it with a random MAC and then changes it.
This causes a race condition: as soon as NM sees the new link, it
starts IP configuration on it and (possibly later) vswitchd will
change the MAC.
To avoid this, also set the desired MAC via netlink before starting IP
configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1852106https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/483
(cherry picked from commit 47ec3d14d4)
(cherry picked from commit 60d10b146d)
When a user creates a ovs-interface with the same name of the parent
ovs-bridge, openvswitch considers the interface as the "local
interface" [1] and assigns the MAC address of the bridge to the
interface [2].
This is confusing for users, as the cloned MAC property is ignored in
some cases, depending on the ovs-interface name.
Instead, detect when the interface is local and set the MAC from the
ovs-interface connection in the bridge table.
[1] https://github.com/openvswitch/ovs/blob/v2.13.0/vswitchd/vswitch.xml#L2546
[2] https://github.com/openvswitch/ovs/blob/v2.13.0/vswitchd/bridge.c#L4744
(cherry picked from commit 5d4c8521a3)
(cherry picked from commit 7548c29a89)
A connection that fails due to dependency-failed is not able to
reconnect until the master connection activates again; when this
happens, the master clears the blocked reason for all its slaves in
activate_slave_connections() and tries to reconnect them. For this to
work, the slave should be marked as blocked when it fails with
dependency-failed.
(cherry picked from commit 725fed01cf)
(cherry picked from commit e1755048e3)
If the device state change (to disconnected or unmanaged) triggered by
a sleep event happens after the wake, the devices becomes wrongly
unmanaged and it's necessary to manually manage it again, or restart
NM.
During the wake event we should disconnect the device_sleep_cb()
callback for all devices because we don't want to react to state
changes anymore; in particular we don't need to detect when the device
becomes disconnected to unmanage it.
(cherry picked from commit fe2d93980b)
(cherry picked from commit 971897195a)
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 75bc21c4cf)
(cherry picked from commit 72d66fffac)
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
(cherry picked from commit e12d32bf56)
(cherry picked from commit 5e5f7574b4)
The commit breaks many nmstate CI tests. It also breaks the
autoconnect-slaves functionality: if the master gets reactivated and
the slave was active, the slave is not reconnected.
A different solution is needed for the original issue.
This reverts commit 024e983c8e.
(cherry picked from commit 6e02622f57)
Autoconnect-slaves currently forces an activation of all slaves, even
if there is already an active connection for them. This is bad because
at boot slaves first try to autoconnect, then the autoconnect-slaves
of the master kicks in and disconnects/reactivates them.
The only reason why the forceful reactivation was added was to fix
[1]; in that scenario, a slave connection is already active as
non-slave; then it is updated to be a slave; later, the master with
autoconnect-slaves is manually activated. NetworkManager should detect
that the slave connection must now be activated by autoconnect-slaves.
Add a specific check for such situation, instead of always
reactivating all slaves.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1845018
Fixes: 4985ca5ada ('manager: allow autoconnect-slaves to reconnect the same connection')
(cherry picked from commit 024e983c8e)
When there are two patch ports connected, each of them must reference
the other; however they can't be created in a single transaction
because they are part of different bridges (so, different
connections). Therefore, the first patch that gets activated will
always fail with "No usable peer $x exists in 'system' datapath" until
the second patch exists.
In theory we could also match the error message, however this doesn't
seem very robust as the message may slightly change in the future.
(cherry picked from commit ffeac35f04)
When searching an element that is lower than the first list element (for
example RTNL type "batadv"), imax will be -1 after the last iteration.
Use int instead of unsigned to make the termination condition imin > imax
work in this case. This fixes NetworkManager crashing due to an
out-of-bounds array access whenever interfaces of such types exist.
Fixes: 19ad044359 ('platform: use binary search to lookup NMLinkType for rtnl_type')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/515
(cherry picked from commit 2b54202089)
When the interface is in IPv4 or IPv6 shared mode and the user didn't
specify an explicit zone, use the nm-shared one.
Note that masquerade is still done through iptables direct calls
because at the moment it is not possible for a firewalld zone to do
masquerade based on the input interface.
The firewalld zone is needed on systems where firewalld is using the
nftables backend and the 'iptables' binary uses the iptables API
(instead of the nftables one). On such systems, even if the traffic is
allowed in iptables by our direct rules, it can still be dropped in
nftables by firewalld.
(cherry picked from commit 3e2b723532)
For ip-tunnel modes that encapsulate layer2 packets (gretap and
ip6gretap) we allow the presence of an ethernet setting in the
connection and honor the cloned-mac-address specified in it.
For all other modes, the ethernet setting is removed during
normalization, but a value different from 'preserve' could be set via
global default.
The kernel doesn't allow setting a MAC for layer3 devices, don't do
it.
(cherry picked from commit 0494a84878)
Reported by coverity:
>>> CID 210222: Null pointer dereferences (NULL_RETURNS)
>>> Dereferencing a pointer that might be "NULL" "f" when calling
"fseek".
Fixes: ac5206aa9c ('2007-11-21')
(cherry picked from commit 581aa981c2)
It is very uncommon that a user provides explicit SSIDs to scan.
So, most of the time there is nothing to do here.
(cherry picked from commit d9740d108d)
Only _scan_request_ssids_track() adds elements to the list, and that already
trims the list to a maxium length. In all other cases, we never expect a need
to trim the list.
(cherry picked from commit 3af9209d47)
We make decisions based on the timestamp. We should only fetch the timestamp
once, and make consistent decisions about that. Don't read different timestamps.
(cherry picked from commit a0e115cb44)
While we are not activated, there is less need to rate limit the scan
requests to 8 seconds. Only rate limit the requests for 1.5 seconds
in that case.
Also, when changing the MAC address, supplicant flushes the AP list.
We should be able to scan right away. Reset the counters for the rate
limiting and periodic scanning.
(cherry picked from commit 12a54a44f8)
As far as NMSupplicantInterface is concerned, don't clamp the
max-scan-ssids to 5. We should track the real value that wpa_supplicant
announces, and it's up to the caller to provide fewer SSIDs.
In particular, we want to limit the number of hidden SSIDs that we
accept from connection profiles, but we don't want to limit the number
of active scans via `nmcli device wifi rescan ssid $SSID [...]`.
(cherry picked from commit c9ae23af5e)
Handling the scanning is complicated.
- we want to have periodic scans. But only at certain times,
and with an increasing back off timeout.
- the user can initiate explicit scans via D-Bus. Thereby a list
of SSIDs scan be provided.
- if there are any hidden Wi-Fi profiles configured, we want
to explicitly scan for their SSIDs.
- explicit scans are not possible at any time. But we should not reject
the scan request, but instead remember to scan later, when possible.
This is a heavy rework. It also aims to fix issues of scanning since
the recent rework of supplicant handling in commit b83f07916a
('supplicant: large rework of wpa_supplicant handling') that can render
Wi-Fi scanning broken.
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling'):
(cherry picked from commit e07fc217ec)
We commonly use already seconds and milliseconds scales for computing timeouts.
Reduce the number of difference scales and don't also use minutes.
(cherry picked from commit f6e438860b)
GObject signals only complicate the code and are less efficient.
Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous
request. Of course, fundamentally emitting a signal *is* the same as
calling a method. However, implementing this as signal is really not
nice nor best practice. For one, there is a (negligible) overhead emitting
a GObject signal. But what is worse, GObject signals are not as strongly
typed and make it harder to understand what happens.
The signal had the appearance of providing some special decoupling of
NMDevice and NMManager. Of course, in practice, they were not more
decoupled (both forms are the same in nature), but it was harder to
understand how they work together.
Add and call a method nm_manager_device_auth_request() instead. This
has the notion of invoking an asynchronous method. Also, never invoke
the callback synchronously and provide a cancellable. Like every asynchronous
operation, it *must* be cancellable, and callers should make sure to
provide a mechanism to abort.
(cherry picked from commit b50702775f)
It's about as complicated to track a CList as it is to track
an allocated array. The latter requires fewer allocations and
has better locality. That makes it preferable.
(cherry picked from commit d935692bc7)
We want that our asynchronous operations are cancellable.
In fact, NMAuthChain is already (manually) cancellable by the
user calling nm_auth_chain_destroy(). However, sometimes we have a
GCancellable at hand, so the callers would have to register to the
cancellable themselves.
Instead, support setting a cancellable to the NMAuthChain, that aborts
the request and invokes the callback.
It does so always on an idle handler. Also, the user may only set the
cancellable once, and only before starting the first call.
(cherry picked from commit ef7fd9e4e3)
NMDevice already has access to the NMSettings singleton. It is permissible that
NMDevice *knows* about NMManager. The current alternative is emitting GObject signals
like NM_DEVICE_AUTH_REQUEST, pretending that NMDevice and NMManager would be completely
independent, or that there could be anybody else handling the request aside NMManager.
No, NMManager and NMDevice may know each other and refer to each other. Just like
NMDevice also knows and refers to NMSettings.
(cherry picked from commit 800ac28cca)
The Station.ConnectHiddenNetwork will provision a network in the iwd
known-networks list. This should allow us to later use the
Network.Connect interface to connect in the future.
(Note: Attempts to use Station.ConnectHiddenNetwork on already provisioned
networks, i.e. networks iwd knows about, will fail.)
This commit squashed several fixups made by thaller.
(cherry picked from commit 69aeed4bdc)
Newer versions of iwd has supported connecting to hidden networks for a
while now. There's a separate "connect-hidden" command in iwctl that
needs to be used instead of the regular "connect" command.
The equivalent on dbus is to use ConnectHiddenNetwork instead of
Connect on the Station interface. NetworkManager however uses the
Network interface and given we the explicit SSID usage we can connect
to hidden networks with that.
This change disabled the explicit check that disallows even attempting
hidden networks when using iwd.
This has been tested to work with a previously known hidden network.
Tests connecting to a previously unknown network has failed.
(cherry picked from commit cd095f49dc)
If a device only has an IPv6 link-local address, we don't generate an
assumed connection. Therefore, when a new slave connection (without IP
configuration) is activated on the device, we don't deactivate any
existing connection and the link-local address remains configured.
The IP configuration of an activated slave should be predictable and
not depend on the previous state; let's flush addresses and routes on
activation.
https://bugzilla.redhat.com/show_bug.cgi?id=1816517https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/480
(cherry picked from commit e302f5ff77)
