This header provides definitions for NET_NAME_UNKNOWN ånd NET_NAME_ENUM
Fixes build issue found with non-glibc systems
../git/src/network/networkd-link.c:1203:52: error: 'NET_NAME_UNKNOWN' undeclared (first use in this function)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
For some reasons I do not know, on interface renaming, kernel once send
netlink message with old interface name, and then send with new name.
If eth0 is renamed, and then new interface appears as eth0, then the
message with the old name 'eth0' makes the interface enters failed
state.
To ignore such invalid(?) rename event messages, let's confirm the
received interface name.
Fixes#20203.
This fixes a bug introduced by fe321d457c.
When we want to update a value (in the case of this commit, it is a hardware
address) which is used as a hashmap key, we need to do the following steps:
1. remove the old hashmap entry,
2. update the value,
3. create a new hashmap entry with the new value.
Previously, if IPv4 ACD is enabled on an address, then we first
assign the address, and start sd-ipv4acd daemon for the address.
This is not only RFC incompliant, but also the address is always
dropped, as the daemon always considers the address is conflicted.
This commit makes networkd first starts sd-ipv4acd daemon to probe
the address, and then the address is configured if no conflict is
detected.
Fixes#17235.
This fixes the following spurious logs on enumerating links:
```
wlan0: Saved original MTU 1500 (min: 256, max: 2304)
wlan0: MTU is changed: 0 → 1500 (min: 256, max: 2304)
```
Most real network devices refuse to set MAC address when its operstate
is not down. So, setting MAC address once failed, then let's bring down
the interface and retry to set.
Closes#6696.
Previously (v248 or earlier), even if no static address is configured,
the link did not enter configured state, as e.g. Link::static_addresses_configured
is false until the link gained its carrier.
But, after the commit 1187fc3375, the
situation was changed. Static addresses, routes, and etc are requested even
if the link does not have its carrier, and thus the link enters configured
state when no static address and etc are specified.
This makes the link does not enter configured state before it gains its
carrier when at least one of dynamic address assignment protocols (e.g.
DHCP) except for NDISC is enabled.
Note that, unfortunately, netplan always enables ConfigureWithoutCarrier=
for all virtual devices, e.g. bridge. See,
https://github.com/canonical/netplan/commit/978e20f902f6b92a46dc6e0050e2172e834e4617
So, we need to support e.g. the following strange config:
```
[Netowkr]
ConfigureWithoutCarrier=yes
DHCP=yes
```
Fixes#19855.
E.g. nexthop requires IFF_UP flag, but the currently stored flag may be
outdated if we called link_down(). This makes such requests pending if
at least one of the flags are updating.
On carrier lost, then all requests which require carrier will not be
processed. And they will be processed when the interface gained its
carrier again. So, it is not necessary to drop requests here.
Khem Raj
Yu Watanabe
Luca Boccassi