| Age | Commit message (Collapse) | Author |
|---|
|
Enhance the test case by generating a Reply. With a properly formed
Reply the callback function will be called and the additional
earlier event loop exit can now be removed.
|
|
Receive and parse a Reply from the server. Set up T1 and T2 timers and
notify the library user of an acquired DHCPv6 lease.
|
|
Enhance the test case by replying with an Advertise message to the
client. Copy the transaction id, IAID and DUID from the Solicit
message. Verify the Request message created by the DHCPv6 client
implementation and move the main loop exit to the end of the Request
message verification.
|
|
As described in RFC 3315, Section 17.1.2, a client has to wait until the
first timeout has elapsed before it is allowed to request IPv6 addresses
from the DHCPv6 server. This is indicated by a non-NULL lease and a
non-zero resend count. Should the Advertisement contain a preference
value of 255 or be received after the first timeout, IPv6 address
requesting is started immediately.
In response to these events, create a Request message and set up proper
resend timers to send the message to the server.
|
|
Update the start function so that the client state can be conveniently
changed with the previous message resend timers cleared. On initial
startup also create and bind to the UDP socket.
|
|
Add a basic test case excersising once more option parsing function
in addition to lease handling. Check that the address iteration
functions return the correct IPv6 address and lifetimes and that
only one address is returned. Also verify that the server ID and
preference values are read correctly.
|
|
Add support functions for accessing the current client lease as well
as iterating over the addresses and get their preferred and valid
lifetimes.
|
|
When receiving DHCPv6 messages, discard the ones that are not meant
for DHCPv6 clients and verify the transaction id. Once that is done,
process the Advertise message and select the Advertise with the
highest preference.
Create a separate function for lease information parsing so that it
can be reused in other parts of the protocol. Verify both DUID and
IAID in the received message and store other necessary information
with the lease structure.
|
|
Add functionality to parse DHCPv6 Identity Association for
Non-temporary (IA_NA) and Temporary Addresses (IA_TA) options.
Both of them contain one or more IA Address (IAADDR) options
and optinally a status code option. Only the IA_NA option
contains lease lifetimes. See RFC 3315, sections 22.4., 22.5.,
22.6., 22.13. and appendix B. for details. If the lease
timeouts are not set, use the ones recommended for servers in
section 22.4.
Factor out common code in the form of an option header parsing
helper function.
|
|
Create a structure describing a DHCPv6 lease. Add internal functions
for creating a new lease and accessing the server ID, preference and
IAID. Provide functions for clearing addresses and associated timers.
External users are initially given only the capabilities of
referencing and unreferencing the lease structure.
|
|
Verify the Solicit message created by the DHCPv6 client code.
Provide local variants for detect_vm(), detect_container() and
detect_virtualization() defined in virt.h. This makes the DHCPv6
library believe it is run in a container and does not try to request
interface information from udev for the non-existing interface index
used by the test case code.
|
|
Implement the initial functionality used for creating a DHCPv6 Solicit
message containing the needed options and send it to the DHCPv6
broadcast address. Increase the sent message count and ensure that
the Solicit Initial Retransmission Time is strictly greater than
the Solicitation IRT as described in RFC 3315, section 17.1.2.
|
|
Add a function that creates a UDP socket bound to the given interface
and optionally to an IPv6 address. Add another function that will
send the DHCPv6 UDP packet to its destination.
Using IPV6_PKTINFO in setsockopt to bind the IPv6 socket to an
interface is documented in section 4. of RFC 3542, "Advanced Sockets
Application Program Interface (API) for IPv6"
Add a define for DHCPv6 Relay Agents and Servers multicast address as
its not available elsewhere.
|
|
Add option appending and parsing. DHCPv6 options are not aligned, thus
the option handling code must be able to handle options starting at
any byte boundary.
Add a test case for the basic option handling.
|
|
Add the core of DHCPv6 client message retransmission and upper bound
timer and message count handling according to RFC 3315 Secions 7.1.2
and 14. Omit the DHCPv6 initial delay; for now it is assumed that
systemd-networkd will provide decent startup randomization that will
desynchronize the clients.
When reinitializing the client, clear all timers.
|
|
Add test cases for basic DHCPv6 client handling, e.g. setting
interface index, mac address and attaching event loop.
|
|
Create structures describing Identity Association IDentifiers and
IPv6 lease addresses.
[tomegun: initialize the IAID when client is started. Base this off of the
predictable udev names, if available, as these satisfy the requirement of
the IAID, and base it off the mac addres otherwise, as that is the best we
have.]
|
|
|
|
Initialize DHCP Unique Identifier when creating the client. The
DUID is generated based on the machine-id, which satisfies all the
requirements of what an DUID should be. The DUID type is DUID-EN.
Based on patch by Patrik Flykt.
|
|
Feed a Router Advertisement to the code and expect proper events
each time. The sending part is ignored, as all of it is static code
in the real dhcp_network_icmp6_send_rs() function.
|
|
Provide functions to bind the ICMPv6 socket to the approriate interface
and set multicast sending and receiving according to RFC 3493, section
5.2. and RFC 3542, sections 3. and 3.3. Filter out all ICMPv6 messages
except Router Advertisements for the socket in question according to
RFC 3542, section 3.2.
Send Router Solicitations to the all routers multicast group as
described in RFC 4861, section 6. and act on the received Router
Advertisments according to section 6.3.7.
Implement a similar API for ICMPv6 handling as is done for DHCPv4 and
DHCPv6.
|
|
Add initial structure definition and functions for setting index, MAC
address, callback and event loop. Define protocol values and states.
|
|
No need to use HASHMAP_ITERATE when we destruct all entries anyway.
|
|
|
|
We must use free instead of dhcp_lease_free here to avoid freeing
client_id.data.
|
|
There is no need to explicitly check version of L3 protocol in the
ethernet header because we bind socket with .sll_protocol set to
ETH_P_IP, thus we only receive IPv4 packets on the socket.
|
|
|
|
For efficiency, we group bytes together before adding them up. This
is guaranteed to always work (regardless of the byte order) as long
as the i-th byte in each group lign up with the i-th byte in each
other group.
On big-endian machines this broke when handling the trailing few bytes
which did not make up a full group of 4 bytes. This patch fixes the
problem by explicitly creating a 4 byte zero-padded group out of the
trailing bytes.
Reported and tested by Thomas Ritter <th.ritter@gmx.at>.
|
|
|
|
static int client_send_request(...) in
./src/libsystemd-network/sd-dhcp-client.c tries to initialize
"request" by calling client_message_init(...), which has atleast
5 error cases where it can return without that happening.
This leads to the function finishing without "request" being initialized.
|
|
|
|
|
|
Make sure we don't hand out the same IP twice. We still don't
handle lease expiry.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We would like to use the UDP socket, but we cannot as we need to specify
the MAC address manually.
|
|
Parse the maximum message size the client can accept and the client id, falling back to
sane defaults if they are not set.
|
|
|
|
We will (at least at first), restrict our focus to running the server
on at most one interface.
|
|
Bind to UDP socket and listen for messages, discarding anything we receive.
|
|
|
|
For this to work nicely we need to use REUSEADDR so that more than one socket
can be open at the same time. Also, we request the ifindex to be appended
to incoming messages, so we know whence it came.
|
|
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.
|
|
|
|
|
