Then, we can start IPv4ACD without adding corresponding Address object
to Link.
Hopefully, no functional change, just refactoring and preparation for
later commits.
Before this patch, if a network has multiple routers and one of them
provides a captive portal, then the portal was overwritten or cleared
when another RA from another router is received.
This makes captive portals managed in the similar way as DNS servers or
DNS domains. So now captive portal can safely handled even if a network
has multiple routers.
This makes a bond or bridge interface in the degraded-carrier state but has a routable address
handled as routable operational state.
If the carrier is degraded but the address state is routable then the operational state should be
seen as routable and not degraded because that may be the case for bonds if some of the links are down,
but when that happens the bond as whole is still routable.
This also makes operational state to degraded if address state is degraded even if the link state is
degraded-carrier.
Fixes#22713.
The setting IPv6AcceptRA= is defaults to yes, hence, even if a .network
file for an interface has static IP address configuration, it may takes
few seconds for the interface being configured state, as NDisc for the
interface needs to be finished. That makes wait-online.service
needlessly slow. Typically, such delay is not necessary for statically
configured networks.
Let's make the required condition slightly relaxed; if a .network file
has static IP address configurations, then let's make the matching
interface enter the 'configured' state soon after the static addresses
configured on the interface.
Note, this does not change the default for IPv6AcceptRA=, hence, NDisc
still runs on interfaces by default. So, addresses, routes, DNS servers,
and so on based on RA will be assigned on interfaces later.
Strictly speaking, this breaks backward compatibility, but the previous
behavior is not clearly documented. If a user requested both static
IPv4 address and IPv6 SLAAC address configured before an interface being
entered to the 'configured' state, then '--ipv6' for wait-online can be
used. So, the behavior change should not cause severe regression.
Closes#27779.
Notable change is,
- UseAddress=no in [DHCPv6],
- Assign=no in [DHCPPrefixDelegation], and
- UseAutonomousPrefix=no in [IPv6AcceptRA]
are gracefully handled now.
When a new wireless network interface is created by the kernel, it emits
both RTM_NEWLINK and NL80211_CMD_NEW_INTERFACE. These events can arrive
in either order and networkd must behave correctly in both cases.
The typical case is that RTM_NEWLINK is handled first, in which case
networkd creates a Link object and starts tracking it. When the
NL80211_CMD_NEW_INTERFACE message is handled, networkd then populates
the Link object with relevant wireless properties such as wireless
interface type (managed, AP, etc.).
In the event that the order is reversed however, networkd will fail to
populate these wireless properties because at the time of processing the
nl80211 message, the link is considered unknown. In that case, a debug
message is emitted:
systemd-networkd[467]: nl80211: received new_interface(7) message for link '109' we don't know about, ignoring.
This is problematic because after the subsequent RTM_NEWLINK message,
networkd will have an incomplete view of the link. In particular, if a
.network configuration matches on some of the missing wireless
properties, such as WLANInterfaceType=, then it will never match.
The above race can be reproduced by using the mac80211_hwsim driver.
Suppose that there exists a .network configuration:
[Match]
WLANInterfaceType=ap
...
Now loop the creation/destruction of such an AP interface:
while true
do
iw dev wlan0 interface add uap0 type __ap
iw dev uap0 del
done
The above debug message from networkd will then be observed very
quickly. And in that event, the .network file will fail to match.
To address the above race, have the nl80211 message handler store the
interface index in a set in case a Link object is not found on
NL80211_CMD_NEW_INTERFACE. The handler for RTM_NEWLINK can then query
this set, and explicitly request the wireless properties from nl80211
upon the creation of the Link object.
When an AP goes up, the kernel may emit a netlink event indicating that
the interface has gained carrier. In that event, we should check if the
SSID has changed before attempting to reconfigure. Not doing so means
that the link->ssid member is not updated, leading to a potential
mismatch if some of the .network configurations match on SSID=.
There are however scenarios where the above heuristic is not enough.
Specifically, if the interface carrier state flip-flops within a short
enough interval, the internal throttling of netlink events inside the
kernel may suppress intermediate linkdown+linkup events (cf. Linux
net/core/link_watch.c). So there is no linkup event to react on.
To improve on the latter scenario, it is proposed to make newer kernels
emit an NL80211_CMD_START_AP multicast event when an AP goes up. This
event will not be dropped by link_watch. systemd-networkd can then react
to such events as well, and optionally reconfigure the link if the SSID
has changed. This will only work with newer kernels though.
Sometimes, RTM_NEWLINK message with carrier is received earlier than
NL80211_CMD_CONNECT. To make SSID= or other WiFi related settings in
[Match] section work, let's try to reconfigure the interface.
Fixes a bug introduced by 96f5f9ef9a.
Fixes#25384.
Previously, interfaces are partially reconfigured in a spurious way.
Let's use the same way as `networkctl reconfigure`.
Hopefully fixes#14987 and #24997.
When at least one of the name, MAC address, udev properties, and so on
for an interface is updated, try to find a matching .network file, and
reconfigure if a new .network file is assigned.
Fixes#24975.
No functional changes, just refactoring and preparation for later
commits.
Note, `link->dev` should always exist when link state is initialized or
later.
We have already allowed to reconfigure failed interface manually, but
not allowed to do automatically, e.g. on carrier gain.
This makes that failed interfaces also reconfigured automatically.
Note, the condition is inversed to shorten the condition.
When a PF port becomes down (this can happens e.g. the PF port is joining
a bond interface), some drivers make its VF ports also become down, and
may cause failures in configuring VF ports.
Similary, when a VF port become down, some drivers make its PF port and
other VF ports down.
Let's configure SR-IOV ports (both PF and VFs) after all link-layer
settings of all ports being applied.
Fixes#23315.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Ronan Pigott
Henrik Holst
Brett Holman
Alvin Šipraga
Luca Boccassi
David Tardon
Andre Kalb