On systems which cannot receive unicast packets until its IP stack has been configured
we need to request broadcast packets. We are currently not able to reliably detect when
this is necessary, so set it unconditionally for now.
This is set on all packets, but the DHCP server will only broadcast the packets that are
necessary, and unicast the rest.
For more information please refer to this thread in CoreOS: https://github.com/coreos/bugs/issues/12
[tomegun: rephrased commit message]
Rely on modules being built-in or autoloaded on-demand.
As networkd is a network facing service, we want to limits its capabilities,
as much as possible. Also, we may not have CAP_SYS_MODULE in a container,
and we want networkd to work the same there.
Module autoloading does not always work, but should be fixed by the kernel
patch f98f89a0104454f35a: 'net: tunnels - enable module autoloading', which
is currently in net-next and which people may consider backporting if they
want tunneling support without compiling in the modules.
Early adopters may also use a module-load.d snippet and order
systemd-modules-load.service before networkd to force the module
loading of tunneling modules.
This sholud fix the various build issues people have reported.
Similar to the previous patch, exchange a length and a pointer with only one offset variable.
Also fix the type of the options to be uint8_t[], rather than uint8_t*.
Store a pointer to the options in the DHCPMessage struct, and pass
this together with an offset around, rather than a uint8_t**.
This avoids us having to (re)compute the pointer; and changes
dhcp_option_append from adjusting both the pointer to the next
option and the remaining size of the options, to just adjusting
the current offset.
This makes the code a bit simpler to follow IMHO, but there should
be no functional change.
close() is a blocking call, which may slow things down measurably when running many dhcp
clients in the same single-threaded main loop. Let's just use the asynchronous version
instead to avoid the problem.
- Also only allow positive ifindex on both dhcp and ipv4ll
[tomegun: the kernel always sets a positive ifindex, but some APIs accept
ifindex=0 with various meanings, so we should protect against
accidentally passing ifindex=0 along.]
To make sure we don't delay boot on systems where (some) network links are managed by someone else
we don't block if something else has successfully brought up a link.
We will still block until all links we are aware of that are managed by networkd have been
configured, but if no such links exist, and someone else have configured a link sufficiently
that it has a carrier, it may be that the link is ready so we should no longer block.
Note that in all likelyhood the link is not ready (no addresses/routes configured),
so whatever network managment daemon configured it should provide a similar wait-online
service to block network-online.target until it is ready.
The aim is to block as long as we know networking is not fully configured, but no longer. This
will allow systemd-networkd-wait-online.service to be enabled on any system, even if we don't
know whether networkd is the main/only network manager.
Even in the case networking is fully configured by networkd, the default behavior may not be
sufficient: if two links need to be configured, but the first is fully configured before the
second one appears we will assume the network is up. To work around that, we allow specifying
specific devices to wait for before considering the network up.
This unit is enabled by default, just like systemd-networkd, but will only be pulled in if
anyone pulls in network-online.target.
This essentially swaps the roles of rtnl and udev in networkd. After this
change libudev is only used for waiting for udev to initialize devices and
to get udev-specific information needed for some [Match] attributes.
This in particular simplifies the code in containers where udev is not really
useful, but also simplifies things and reduces round-trips in the non-container
case.
Also reshuffle some code to make the correspondence with the RFC a bit more
obvious.
Small functional change: fail if we try to send a message from the wrong state.
Add an explicit stop state for IPv4LL so that the user can stop the
IPv4LL client from the callback. When returning from the callback,
check also the stop state in order to halt any further protocol
processing.
Similar to DHCP, the IPv4LL library user can decide to free the LL
client any time the callback is called. Guard against freeing the
LL client in the callback by introducing proper reference counting.
Also update code using the IPv4LL library to properly handle a
returned NULL from the notify and stop functions if the IPv4LL
client was freed.
Add an explicit stop state for the DHCP client so that the library
user can issue a stop at any time the callback has been called.
When returning from the callback, check also the stop state and
stop any further DHCP processing.
The DHCP library user can decide to free the DHCP client any time
the callback is called. After the callback has been called, other
computations may still be needed - the best example being a full
restart of the DHCP procedure in case of lease expiry.
Fix this by introducing proper reference counting. Properly handle
a returned NULL from the notify and stop functions if the DHCP
client was freed.
Improve the checksum computation by using 64 bit integers instead of the 16 bit
integers in the existing implementation. This change speeds up the computation
with approximately 78% both on 64 bit and 32 bit systems.
Please see RFC 1071 for details.
Camilo Aguilar
Tom Gundersen
Cristian Rodríguez
Susant Sahani
Umut Tezduyar Lindskog
Zbigniew Jędrzejewski-Szmek
Patrik Flykt