| Age | Commit message (Collapse) | Author |
|---|
|
Udev does not run in containers, so instead of relying on it to tell us when a
network device is ready to be used by networkd, we simply assume that any
device was fully initialized before being added to the container.
|
|
This fixes a regression introduced in 672682a6b
|
|
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>
|
|
|
|
|
|
Both in the configuration file format and everywhere else in the code.
|
|
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.
|
|
|
|
|
|
|
|
The kernel will not be changed to support this, so drop the code. Listening
for all RTM_NEWLINK messages and filtering on name is reliable, so it is not
a problem.
|
|
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.
|
|
This was originally included in the dhcp-client at my request, but it is not
really dhcp-specific and useful outside of it, so let's pull it out.
|
|
|
|
Error out if the address family is already set to something incompatible with the
address being parsed.
|
|
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.
|
|
Fix/add some structured logging messages, and be uniform about when we WARN and ERR.
|
|
|
|
Split out into sd_rtnl_message_addr_set_{prefixlen,flags,scope}().
|
|
Refactor bridging support to be generic netdev support and extend it to
cover bonding as well.
|
|
|
|
|
|
|
|
Make them more simiar to sd_bus and friends. Also factor out the event attachment. In the future,
we will likely want to support external main-loops, so this is a first step. For the time being,
we are still requiring an sd_event to be attached though.
|
|
|
|
We may not have a dbus daemon in the initrd (until we can rely on kdbus). In
this case, simply ignore any attempts at using the bus. There is only one user
for now, but surely more to come.
In order to work reliably in the real root without kdbus, but at the same time
don't delay boot when kdbus is in use, order ourselves after dbus.service.
|
|
Take into account that users may want to use resolvconf(8), or similar. Also,
avoid repeated calls to fputs().
|
|
|
|
Rather than keeping an array of pointers to addresses, just keep an array of addresses.
|
|
|
|
Only set MTU request when creating the dhcp client, not every time it is restarted.
|
|
|
|
|
|
|
|
Setting UseDNS=no will ignore any received DNS servers.
|
|
|
|
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.
|
|
We don't know if the config will be consistent, so do as systemd itself and only
load config when the daemon starts (and possibly, in the future, when explicitly requested).
|
|
|
|
Thanks David!
|
|
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 debug information may be useful when comapring to dropped rtnetlink messages.
|
|
This gives a bit better messages when a link is added twice.
|
|
|
|
|
