Devices with multicast but without mac addresses i.e. tun devices
are not getting setuped correctly:
$ ip tuntap add mode tun dev tun0
$ ip addr show tun0
16: tun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 500
link/none
$ cat /etc/systemd/network/tun0.network
[Match]
Name = tun0
[Network]
Address=192.168.1.1/32
$ ./systemd-networkd
tun0: DHCP6 CLIENT: Failed to set identifier: Invalid argument
tun0: Failed
Follow-up for ac24e418d9.
The original motivation of the commit and RFE #15339 is to start dhcpv6
client in managed mode when neither M nor O flag is set in the RA.
But, previously, if the setting is set to "always", then the DHCPv6
client is always started in managed mode even if O flag is set in the
RA. Such the behavior breaks RFC 7084.
The configuration of networkd has a DHCPv6Client setting in its
[IPv6AcceptRA] section, which, according to the man page, can be
a boolean, or the special value "always". The man page states
that "true" is the default.
The default value is implemented in src/network/networkd-network.c
by setting field ipv6_accept_ra_start_dhcp6_client of network to
true. However, this field is not a boolean, but an enum type
IPv6AcceptRAStartDHCP6Client (src/network/networkd-ndisc.h).
Setting ipv6_accept_ra_start_dhcp6_client to true effectively
corresponds to the enum value IPV6_ACCEPT_RA_START_DHCP6_CLIENT_ALWAYS,
resulting in the DHCPv6Client setting having the default value
"always".
This patch changes the initialisation to the correct enum value
IPV6_ACCEPT_RA_START_DHCP6_CLIENT_YES.
This is useful for development where overwriting files out side
the configured prefix will affect the host as well as stateless
systems such as NixOS that don't let packages install to /etc but handle
configuration on their own.
Alternative to https://github.com/systemd/systemd/pull/17501
tested with:
$ mkdir inst build && cd build
$ meson \
-Dcreate-log-dirs=false \
-Dsysvrcnd-path=$(realpath ../inst)/etc/rc.d \
-Dsysvinit-path=$(realpath ../inst)/etc/init.d \
-Drootprefix=$(realpath ../inst) \
-Dinstall-sysconfdir=false \
--prefix=$(realpath ../inst) ..
$ ninja install
This beefs up the READ_FULL_FILE_CONNECT_SOCKET logic of
read_full_file_full() a bit: when used a sender socket name may be
specified. If specified as NULL behaviour is as before: the client
socket name is picked by the kernel. But if specified as non-NULL the
client can pick a socket name to use when connecting. This is useful to
communicate a minimal amount of metainformation from client to server,
outside of the transport payload.
Specifically, these beefs up the service credential logic to pass an
abstract AF_UNIX socket name as client socket name when connecting via
READ_FULL_FILE_CONNECT_SOCKET, that includes the requesting unit name
and the eventual credential name. This allows servers implementing the
trivial credential socket logic to distinguish clients: via a simple
getpeername() it can be determined which unit is requesting a
credential, and which credential specifically.
Example: with this patch in place, in a unit file "waldo.service" a
configuration line like the following:
LoadCredential=foo:/run/quux/creds.sock
will result in a connection to the AF_UNIX socket /run/quux/creds.sock,
originating from an abstract namespace AF_UNIX socket:
@$RANDOM/unit/waldo.service/foo
(The $RANDOM is replaced by some randomized string. This is included in
the socket name order to avoid namespace squatting issues: the abstract
socket namespace is open to unprivileged users after all, and care needs
to be taken not to use guessable names)
The services listening on the /run/quux/creds.sock socket may thus
easily retrieve the name of the unit the credential is requested for
plus the credential name, via a simpler getpeername(), discarding the
random preifx and the /unit/ string.
This logic uses "/" as separator between the fields, since both unit
names and credential names appear in the file system, and thus are
designed to use "/" as outer separators. Given that it's a good safe
choice to use as separators here, too avoid any conflicts.
This is a minimal patch only: the new logic is used only for the unit
file credential logic. For other places where we use
READ_FULL_FILE_CONNECT_SOCKET it is probably a good idea to use this
scheme too, but this should be done carefully in later patches, since
the socket names become API that way, and we should determine the right
amount of info to pass over.
When selinux is enabled, the call of
manager_rtnl_enumerate_nexthop() fails.
This fix is to facilitate selinux hook handling for enumerating
nexthop.
In manager_rtnl_enumerate_nexthop() there is a check
if "Not supported" is returned by the send_netlink() call.
This check expects that -EOPNOTSUPP is returned,
the selinux hook seems to return -EINVAL instead.
This happens in kernel older than 5.3
(more specificallytorvalds/linux@65ee00a) as it does not support
nexthop handling through netlink.
And if SELinux is enforced in the order kernel, callingRTM_GETNEXTHOP
returns -EINVAL.
Thus adding a call in the manager_rtnl_enumerate_nexthop for the
extra return -EINVAL.
With these patches applied, networkd is successfully able to get an
address from a DHCP server on an IPoIB interface.
1)
Makes networkd pass the actual interface type to the dhcp client,
instead of hardcoding it to Ethernet.
2)
Fixes some issues in handling the larger (20 Byte) IB MAC addresses in
the dhcp code.
3)
Add a new field to networkds Link struct, which holds the interface
broadcast address.
3.1)
Modify the DHCP code to also expect the broadcast address as parameter.
On an Ethernet-Interface the Broadcast address never changes and is always
all 6 bytes set to 0xFF.
On an IB one however it is not neccesarily always the same, thus
fetching the actual address from the interface is neccesary.
4)
Only the last 8 bytes of an IB MAC are stable, so when using an IB MAC to
generate a client ID, only pass those 8 bytes.
This passes the legacy ethernet address to functions in a lot of places,
which all will need migrated to handle arbitrary size hardware addresses
eventually.
The link state file is always removed when networkd is stopping. So,
the deserialization logic does not work. Moreover, the ADDRESSES=
entry is not used by sd-network, so serialization is also not necessary.
The link state file is always removed on stop. So, we cannot deserialize
the address from the file. Moreover, currently the IPv4 link-local address
is always dropped by link_drop_foreign_addresses() on restart. Let's
drop the serialize/deserialize logic for IPv4 LL address.
Previously, the address was taken from the state file, but DHCP4_ADDRESS=
entry was dropped by 46986251d6.
Moreover, the link state file is always removed when networkd is
stopping. Let's take the address from the list of enumerated addresses.
These should not be bundled into the link_up() operation, as that is
not (currently) called during interface configuration if the interface
already is IFF_UP, which is unrelated to the need to change the mac
to a user-defined value, or set 'nomaster' on the interface.
Additionally, there is no need to re-set the mac or re-assert nomaster
every time the interface is brought up; those should be only part of
normal initial interface configuration.
Fixes: #17391
`route_get()` compares input with existing routes, however previously,
the input may did not have information about gateway. So, the
comparison result might be incorrect, and the foregoing set_put() might
return -EEXIST.
