Provide names to choose between different auto-generation types:
2.1 "eui64" for EUI-64 of RFC 4291
2.2 "prefixstable" for RFC 7217
```
[Match]
Name=veth99
[Network]
DHCP=no
IPv6AcceptRA=yes
IPv6Token=prefixstable:2001:888:0db8:1::
```
This never made into a release, so we can change the name with impunity.
Suggested by Davide Pesavento.
I opted to add the "ing" ending. "Fair queuing" is the name of the general
concept and algorithm, and "Fair queue" is mostly used for the implementation
name.
Two releases ago we started warning about this, and I think it is now to turn
this into a hard error. People get bitten by this every once in a while, and
there doesn't see to be any legitimate use case where the same .link or
.network files should be applied to _all_ interfaces, since in particular that
configuration would apply both to lo and any other interfaces. And if for
whatever reason that is actually desired, OriginalName=* or Name=* can be
easily added to silence the warning and achieve the effect.
(The case described in #12098 is particularly nasty: 'echo -n >foo.network'
creates a mask file, 'echo >foo.network' creates a "match all" file.)
Fixes#717, #12098 for realz now.
We'd just print nothing and exit with 0. If the user gave an explicit
name, we should fail. If a pattern didn't match, we should at least warn.
$ networkctl status enx54ee75cb1dc0a* --no-pager && echo $?
No interfaces matched.
0
$ networkctl status enx54ee75cb1dc0a --no-pager
Interface "enx54ee75cb1dc0a" not found.
1
We don't need a seperate output parameter that is of type int. glibc() says
that the type is "unsigned", but the kernel thinks it's "int". And the
"alternative names" interface also uses ints. So let's standarize on ints,
since it's clearly not realisitic to have interface numbers in the upper half
of unsigned int range.
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.
