We'd start writing an entry line, then another one, then another one,
and then output the rest of the first one, and then some other random
stuff, and the rest of some other lines... Results were ...eh... random.
Let's define a helper to avoid some of the copy&paste madness, and separate
blocks that output a single line with /**********************************/.
This rework doesn't change what data is written, it only tries to fix the
format of the output. The fact that some entries only write data from
link->network, and some from either link->network or link, some stuff only
for dhpc4 leases while some for both dhpc4 and dhcp6, etc, looks rather
suspicious too, but I didn't touch this.
Link groups are similar to port ranges found in managed switches.
You can add network interfaces to a numbered group and perform operations
on all the interfaces from that group at once.
Commit 08c588d18b moved attachment of the
sd-event into creation of the dhcp_client or ipv4ll in dhcp4_configure()
or ipv4ll_configure(), but these can also be created in link_load(),
so that creation needs to also perform sd-event attachment.
Without this, dhcp_client or ipv4ll created in link_load() will not have
an ->event and will fail assertion, causing networkd to fail, e.g.:
Assertion 'client->event' failed at src/libsystemd-network/sd-dhcp-client.c:1283, function client_start_delayed(). Ignoring.
ens2: Could not acquire DHCPv4 lease: Invalid argument
ens2: Failed
Interfaces may come up at any time, even during our initialization of
them, for various reasons; e.g. the kernel will raise VLAN when its
parent is raised; or we will raise an interface if configured with
BindCarrier and its associated interfaces come up.
When LinkLocalAddressing has been disabled for ipv6, we disable
addr_gen_mode in the kernel, so it will not automatically create a
ipv6ll address when the interface is raised. However, we currently
drop all foreign addresses before disabling addr_gen_mode.
If the link has been up for a long time, then its kernel-created ipv6ll
address will be correctly dropped. If the link is down, and stays
down until we raise it after finishing configuration, the addr_gen_mode
setting will be disabled when the interface is raised and the kernel
will not create any ipv6ll address.
However, if the interface is raised after dropping foreign config,
but before we have disabled addr_gen_mode, the kernel will create a
ipv6ll tentative address that will eventually finish DAD and become a
working ipv6ll address, even though we have been configured to disable
ipv6ll.
Moving our call to drop foreign addresses to after we have successfully
set addr_gen_mode closes this window; after we disable addr_gen_mode,
we can safely remove foreign ipv6ll addresses (including tentative ones)
and be sure that the kernel will not create any more.
Fixes: #13882.
The kernel will create an ipv6ll tentative address immediately when an
interface is raised if addr_gen_mode is not disabled; and, the kernel does
not notify netlink listeners about any tentative addresses. So it's
possible for an interface to contain tentative ipv6 link-local address(es)
that networkd doesn't know about when all foreign addresses are dropped.
In this case, networkd is later notified about the new ipv6ll address(es)
after they finish DAD and are no longer tentative; but since that's after
networkd has already dropped foreign addresses, they are incorrectly left
on the interface.
Similar to the link->setting_mtu flag, this delays continued configuration
until after the genmode has been successfully set; this is important
because we do not want networkd to raise the interface before the genmode
has been set, as if we're disabling the genmode, raising the interface
before we have successfully disabled the genmode will result in the kernel
creating a ipv6ll address, even though we don't want that.
If the interface is in initialized state, no network file is assigned to
the interface. If an interface is not managed by networkd, previously,
the foreign configs of the interface was dropped.
Fixes#14250.
The kernel resets the ipv6 mtu after NETDEV_UP or NETDEV_CHANGEMTU event,
so we must reset the ipv6 mtu to our configured value after we detect
IFF_UP flag set or after we set the device mtu.
Fixes: #13914.
This switches detect_container() to path_is_read_only_rw("/sys"), as if
systemd-udevd.service is conditionalized with that way.
This also updates the log message.
Zbigniew Jędrzejewski-Szmek