See kernel's rtm_to_fib_config() in net/ipv4/fib_frontend.c and
rtm_to_fib6_config() in net/ipv6/route.c.
Note that if both gateway and multipath routes are specified, then
kernel ignores gateway. So, strictly speaking, setting both gateway and
multipath routes is allowed by kernel. But such situation is mostly
user's misconfiguration. Let's refuse it.
Note that the conditions newly added in route_configure() are redundant,
as all static configurations are already verified in
route_section_verify(), and dynamic configurations do not set
nexthop_id or multipath routes. Just for safety.
Usually, removing non-existing addresses, routes, and etc, are safe.
However, when multiple interfaces lost their carriers simultaneously,
then manager_drop_routes() and manager_drop_nexthop() are called multiple
times. If a route with a blackhole nexthop is removed in that process,
the later removal requests of the route fail with -EINVAL, rathar
than -ESRCH, as the corresponding nexthop does not exist anymore.
So, let's not remove routes which managed by Manager more than once.
This allows to limit units to machines that run on a certain firmware
type. For device tree defined machines checking against the machine's
compatible is also possible.
We were duplicating setting flags for the message and a combination of
NLM_F_APPEND and NLM_F_CREATE which does not make sense. We should have
been using NLM_F_REPLACE and NLM_F_CREATE since the kernel can
dynamically create neighbors prior to us adding an entry. Otherwise, we
can end up with cases where the message will time out after ~25s even
though the neighbor still gets added. This delays the rest of the setup
of the interface even though the error is ultimately ignored.
After 4b30f2e135, reading stable_secret
sysctl property fails with -ENOMEM, instead of -EIO.
This is due to read_full_virtual_file() uses read() as the backend while
read_one_line_file() uses fgetc(). And each functions return different
error on fails.
Anyway, the failure is harmless here. So, the log message and comment is
updated.
Closes one of the issues in #19410.
Some interfaces require that the DHCPOFFER message is sent via broadcast
if they can't receive unicast messages before they've been configured
with an IP address.
E.g., s390 ccwgroup network interfaces operating in layer3 mode face
this limitation. This can prevent the interfaces from receiving an
IP address via DHCP, if the have been configured for layer3.
To allow DHCP over such interfaces, we're introducing a new device
property ID_NET_DHCP_BROADCAST which can be set for those.
The networkd DHCP client will check whether this property is set
for an interface, and if so will set the broadcast flag, unless
the network configuration for the interface has an explicit
RequestBroadcast setting.
Besides that, we're adding a udev rule to set this device property
for ccwgroup devices operating in layer3 mode, which is the case
if the ID_NET_DRIVER property is qeth_l3.
Supercedes #18829
Previously, if DUID-UUID is used, all configurations are configured
after networkd gets product uuid of machine.
This makes only DHCP clients are delayed, and other configs are
configured earlier.
