Don't set set **ret when returning r < 0, as matching on the errno may easily
give false positives in the future leading to null pointer dereference.
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Also limit the range of vlan ids. Other implementations and
documentation use the ranges {0,1}-{4094,4095}, but we use
the one accepted by the kernel: 0-4094.
Reported-by: Oleksii Shevchuk <alxchk@gmail.com>
This allows us users of the library to keep copies of old leases. This is
used by networkd to know what addresses to drop (if any) when the lease
expires.
In the future this may be used by DNAv4 and sd-dhcp-server.
When creating a new link, the kernel will not inform us about the new ifindex
in its ack. We have to listen for newly created devices and deduce the new
ifindex by matching on the ifname.
We used to do this by waiting for a new device from libudev, but that is asking
for trouble, as udev will happily rename the device before handing it to us.
Listen on rtnl instead, the chance of the name being changed before reaching us
is much smaller (if not nil).
Kernel patch in the works to make this unneccessary.
These connections are never torn down, even when the DHCP specifications say that
they should be. This is useful/necessary when the rootfs (or another critical fs)
is mounted over this network connection, and dataloss would result if the connection
is lost.
This option defaults to off, but our initrd generator (TBD) will enable it when
applicable.
This adds support to generate a basic resolv.conf in /run/systemd/network.
This file will not take any effect unless a symlink is created from
/etc/resolv.conf.
Nameservers received over DHCP takes precedence over statically configured ones.
Note: /etc/resolv.conf is severely limited, so in the future we will likely
rather provide a much more powerfull nss plugin (or something to that effect),
but this should allow current users to function without any loss of
functionality.
We will not insist on getting the reply from rtnl that the bridge
was created before considering the bridge ready, as we will be
notified about that via udev. We will listen for the rtnl response
however, in case the creation of the bridge failed.
It seems that networkd stores in_addr.s_addr contents in reverse
order (little-endian, not network order). This is a bit confusing,
but sd_rtnl evidently likes this order.
These keys are mandatory in [Address]/[Route] sections. Otherwise, we
hit an assert:
ens3: setting addresses
Assertion 'address->family == 2 || address->family == 10' failed at /build/amd64-generic/tmp/portage/sys-apps/systemd-9999-r1/work/systemd-9999/src/network/networkd-address.c:137, function address_configure(). Aborting.
Reported-by: Alex Polvi <alex.polvi@coreos.com>
At the same time make sure Route's Destination and Gateway uses the same address family.
This adds basic DHCPv4 support. Link-sense is enabled unconditionally,
but the plan is to make that configurable.
I tested this in a VM with lots of NICs and over wifi in the various
coffee shops I found this Christmas, but more testing would definitely
be appreciated.
Static addresses/routes are associated with a network. Dynamic
addresses/routes are associtade with links (as the corresponding network
may be shared by several links).
This listens to rtnetlink for changes to IFF_UP and IFF_LOWER_UP (link sense). The latter
is simply logged at the moment, but will be useful once we add dhcp support.
A bridge is specified in a .netdev file with a section [Bridge]
and at least the entry Name=.
A link may be joined to a bridge if the .network applied to it has
a Bridge= entry giving the name of the bridge in its [Network] section.
We eagerly create all bridges on startup, and links are added to
bridges as soon as they both appear.
This will allow specifying more options per address than the
simple Address= entry in the [Network] section.
Preliminary support for the same functionality for [Route] sections
are added, but not yet hooked up, as more testing is needed.
Pass on the line on which a section was decleared to the parsers, so they
can distinguish between multiple sections (if they chose to). Currently
no parsers take advantage of this, but a follow-up patch will do that
to distinguish
[Address]
Address=192.168.0.1/24
Label=one
[Address]
Address=192.168.0.2/24
Label=two
from
[Address]
Address=192.168.0.1/24
Label=one
Address=192.168.0.2/24
Label=two
This daemon listens for and configures network devices tagged with
'systemd-networkd'. By default, no devices are tagged so this daemon
can safely run in parallel with existing network daemons/scripts.
Networks are configured in /etc/systemd/network/*.network. The first .network
file that matches a given link is applied. The matching logic is similar to
the one for .link files, but additionally supports matching on interface name.
The mid-term aim is to provide an alternative to ad-hoc scripts currently used
in initrd's and for wired setups that don't change much (e.g., as seen on
servers/and some embedded systems).
Currently, static addresses and a gateway can be configured.
Example .network file:
[Match]
Name=wlp2s0
[Network]
Description=My Network
Gateway=192.168.1.1
Address=192.168.1.23/24
Address=fe80::9aee:94ff:fe3f:c618/64
