Although this slightly more verbose it makes it much easier to reason
about. The code that produces the tests heavily benefits from this.
Test lists are also now sorted by test name.
RFC3442 specifies option 121 (Classless Static Routes) that allow a DHCP
server to push arbitrary routes to a client. It has a Local Subnet
Routes section expliciting the behavior of routes with a null (0.0.0.0)
gateway.
Such routes are to be installed on the interface with a Link scope, to
mark them as directly available on the link without any gateway.
Networkd currently drops those routes, which is against the RFC, as
Linux has proper support for such routes.
Fixes: 7f20627 ("network: dhcp4: ignore gateway in static routes if destination is link-local or in the same network")
The commit 0f707207b9 enables strong
warning about missing prefix length in Address= setting.
The change was done in v241, and was about 4 years ago.
Let's drop the legacy assumption and make the parser consistent with
'ip address' command.
C.f. #11307.
Closes#26102.
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.
Previously, when neither '--any' nor '--interface' options specified,
at least one of the interfaces must be in configured state.
This patch makes wait-online exit with success even if all interfaces
are in unmanaged state.
This may break backward compatibility in a rare situation. But in most
cases, this typically not change anything, as at least one interface
is managed by networkd.service when it is enabled.
This is mostly for making wait-online gracefully handle the case that
networkd.service and wait-online.service are enabled by mistake. In such
situation, all interfaces are typically not managed.
Fixes#25813.
-1 was used everywhere, but -EBADF or -EBADFD started being used in various
places. Let's make things consistent in the new style.
Note that there are two candidates:
EBADF 9 Bad file descriptor
EBADFD 77 File descriptor in bad state
Since we're initializating the fd, we're just assigning a value that means
"no fd yet", so it's just a bad file descriptor, and the first errno fits
better. If instead we had a valid file descriptor that became invalid because
of some operation or state change, the other errno would fit better.
In some places, initialization is dropped if unnecessary.
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.
This effectively reverts 5d0030310c.
With the commit 5d0030310c, networkd manages
addresses with the detailed hash and compare functions. But that causes
networkd cannot detect address update by the kernel or an external tool.
See issue
https://github.com/systemd/systemd/issues/481#issuecomment-1328132401.
With this commit, networkd (again) manages addresses in the way that the
kernel does. Hence, we can correctly detect address update.
When an interface goes to down, the kernel drops several routes
automatically, and at the same time networkd requests to remove
them, but the kernel sometimes does not respond the requests. Hence,
the routes cannot drop the REMOVING flag, and networkd will never try
to configure other routes which depend on the previously removed
routes even if they are already reconfigured.
With this patch, when networkd sends a request to configure a route
(or any other network settings), REMOVING flag for the route is dropped
without waiting for the reply about the previous remove request, as we
can expect it will appear even if it is already removed or under removing.
Fixes#24999.
Issue:
When device is in bond mode and booting up, there is a probability of
set bond MAC address failed due to `Device or resource busy` error.
In systemd-networkd, set MAC address steps are:
1. Try to set MAC address to device.
2. If failed with `Device or resource busy`, then `Down` the device.
3. Try to set MAC address to device again.
Currently, Even down the bond device, the bond device is still return
`Device or resource busy` error. So the MAC address set failed.
The root cause is that this not enough to down the bond device. We need
to down all the slaves of the bond device.
About this descprition, we could use those commands to check:
```shell
We have two network devices: eth0, bond1, eth0 is slave of bond1.
They are all up.
1. Down bond1, and set MAC address to bond1.
~# ip link set bond1 down
~# ip link set bond1 address 00:11:22:33:44:55
ip: SIOCSIFHWADDR: Device or resource busy
2. Down eth0, and set MAC address to bond1.
~# ip link set eth0 down
~# ip link set bond1 address 00:11:22:33:44:55
Set okay.
```
Fix:
When setting the mac for the second time, if the device kind is bond,
then we need to down the slave devices of bond device.
Tested: Verified in a long time test( reboot cycles ).
Fixes: #25627
Signed-off-by: Jian Zhang <zhangjian.3032@bytedance.com>
This fixes an issue introduced by af2aea8bb6.
When an outdated address or route is passed to link_request_address()/route(),
then they return 0 and the address or route will not be assigned. Such
situation can happen when we receive RA with zero lifetime. In that
case, we should not unset Link.ndisc_configured flag, otherwise even
no new address nor route will assigned, the interface will enter to the
configuring state, and unnecessary DBus property change is emit and the state
file will be updated. That makes resolved or timesyncd triggered to
reconfigure the interface.
Fixes#25456.
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.
This helps in avoiding compiling errors on musl. Definition of
IFF_LOOPBACK is the reason for including linux/if_arp.h, this however
could be obtained from net/if.h glibc header equally and makes it
portable as well.
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
I changed imports of util.h to initrd-util.h, or added an import of
initrd-util.h, to keep compilation working. It turns out that many files didn't
import util.h directly.
When viewing the patch, don't be confused by git rename detection logic:
a new .c file is added and two functions moved into it.
Previously, interfaces are partially reconfigured in a spurious way.
Let's use the same way as `networkctl reconfigure`.
Hopefully fixes#14987 and #24997.
Lennart Poettering
Jan Janssen
Yu Watanabe
Tuetuopay
Luca Boccassi
chris
Daan De Meyer
Alvin Šipraga
chris
Zbigniew Jędrzejewski-Szmek
Jian Zhang
Khem Raj