| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
|
|
|
|
No need to wait for the NEWLINK message to arrive.
|
|
|
|
|
|
|
|
|
|
If a network is not (yet) set for a link, we do not care about its state (as we
anyway don't know what to do with it).
|
|
Remove redundant messages, add some debugging ones and make wording more uniform.
|
|
|
|
We were requesting the state and then ignoring it...
|
|
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).
|
|
|
|
matches
Instead of checking each device after we got it, check wuth an
enumeration filter instead, to make it more efficient.
|
|
udev initialization
Managers shouldn't pick up the devices the manage before udev finished
initialization, hence check explicitly for that.
|
|
We were entering BRIDGE_STATE_CREATED rather than BRIDGE_STATE_READY.
|
|
Rework the state-machine a bit.
|
|
We are likely to track more than the flags in the future.
|
|
|
|
|
|
|
|
|
