When networkd detects a wlan interface, the interface may not be
connected to any access point, and may enter the unmanaged state.
After the interface connected to an access point, previously networkd
did not reconfigure the interface. This fixes the issue.
No IFLA_PROP_LIST attribute contained does not means the interface
has no alternative name.
E.g. the message created by inet6_fill_ifinfo() in net/ipv6/addrconf.c
does not contain IFLA_PROP_LIST.
This fixes the following error:
---
systemd-networkd[1449490]: ip6tnl0: Saved hardware address: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
systemd-networkd[1449490]: ip6tnl0: Failed to manage link by its new hardware address, ignoring: File exists
---
When a .network file is updated but its change is not so big, it is not
necessary to first drop all configs and then reassign later again.
This slightly optimize such situation. First foreignize all configs, and
then drop later when it is not requested by the updated .network file.
Also,
- drop unnecessary +1 from buffer size, as IF_NAMESIZE or IFNAMSIZ
includes the nul at the end.
- format_ifname() does not update buffer on failure,
- introduces format_ifname_alloc(), FORMAT_IFNAME(), and their friends.
Currently, link_stop_engines(), link_drop_config(), and link_drop_foreign_config()
do nothing when the interface is unmanaged. So this does not change anything.
But returning earlier should be clear and safer for protecting configs
on unmanaged interfaces.
Previously, when UUID is requested for DUID, then the clients are
configured in callback of bus methods.
But now, 'request queue' was implemented, so we can use it to wait until
the product UUID is obtained.
Then, link_acquire_dynamic_conf() matches link_stop_engines().
Previously, LLDP client is started on interface is up, and stopped
on both down and carrier loss.
Previously, link was reconfigured with `link_carrier_reset()`, but it
just re-request to configure static addresses, routes, etc, and restart
engines (e.g. DHCP client).
However, after coming back from sleep, several link information may be
changed, especially the wifi access point may be different. So, we may
need to reconfigure the interface.
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
Yu Watanabe
Luca Boccassi
Zbigniew Jędrzejewski-Szmek