| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
sd_dhcp6_client_new() tried to set the DUID based on the machine id.
If the host has no /etc/machine-id, the constructor would fail
making it impossible to create an sd_dhcp6_client instance.
Relax this and create a DUID only later as needed. This way a caller
caller can workaround a missing machine-id file and set a DUID of his
choosing via sd_dhcp6_client_set_duid().
|
|
This will also be used in dhcp4-client.
|
|
We will use the same in both dhcp4 and dhcp6.
|
|
|
|
This does not make a difference, but the code was confusing.
|
|
Start the DHCPv6 test case by sending an Information Request, verifying
the reply and continuing at once with the normal address acquisition
procedure. Reuse the DHCPv6 Solicit Reply so that the client code is
verified to ignore any erroneously added IPv6 address information.
|
|
Implement Information Request message according to RFC 3315, section
18.1.5. with the excepion that the first message is not delayed by a
random amount. Instead systemd-networkd is supposed to take care of
desynchronizing between other clients.
Initialize the DHCPv6 client structure in sd_dhcp6_client_start()
as this allows toggling between information request and normal
DHCPv6 address aquisition modes.
|
|
When all DHCPv6 options have been parsed, dhcp6_option_parse() returns
-ENOMSG. Explicitely set the return value to indicate success so that
later code does not need to take this special value into account.
|
|
To mirror the recent name change of the concept for sd_bus objects,
follow the same logic for sd_event_source objects, too.
|
|
The duid data passed by the caller does not include the DUID type,
but sd_dhcp6_client_set_duid() was treating it like it did.
|
|
Like Infiniband. See RFC 4390 section 2.1 for details on DHCP
and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
is set to ARPHRD_INFINIBAND because IB hardware addresses
are 20 bytes in length.
|
|
|
|
This would make it simple to verify that the data is on the right format when
the type is known.
|
|
|
|
The caller may have an existing DUID that it wants to use, and may
want to use some other DUID generation scheme than systemd's
default DUID-EN.
[tomegun: whitespace - we never use tabs]
|
|
Implement Elapsed Time option as it is defined as MUST in RFC 3315,
section 22.9. The elapsed time value is a 1/100th of a second with
a max value of 0xffff, i.e. 655.35 seconds.
As the main loop might not be running yet when sd_dhcp6_client_start() is
called, fetch the monotonic time directly and not from the event loop
while in state DHCP6_STATE_STOPPED.
|
|
Also make pointer calculations more explicit so they are
easier to understand.
|
|
This should help in debugging failing event sources.
|
|
|
|
The timeouts in the networking library (DHCP lease timeouts and similar) should not be affected
by suspend. In the cases where CLOCK_BOOTTIME is not implemented, it is still safe to fallback to
CLOCK_MONOTONIC, as the consumers of the library (i.e., networkd) _should_ renew the leases when
coming out of suspend.
|
|
Probably a left-over from when router solicitations were
requested in the DHCP6 code. But since they are now separate,
this state is no longer needed.
|
|
It complains about {max,init}_retransmit_time possibly being
uninitialized. It is wrong, but let's just initialize it.
|
|
If client->lease is NULL, dhcp6_lease_clear_timers will cause a segmentation
fault.
|
|
|
|
Checking the return values seems to have been forgotten in
ed6ee21953dac9c78383da00bc4514ece6b75ab5
|
|
|
|
Add a Rapid Commit option to Solicit messages and expect a Reply to
be received instead of an Advertise. When receiving a DHCPv6 message
from the server in state Solicit, continue testing whether the
message is a Reply. Ease up the message type checking, it's not fatal
if the message is of a wrong type.
Add helper functions to set/get the rapid commit of a lease. See
RFC 3315, sections 17., 17.1.2., 17.1.4. and 18.1.8.
|
|
Start sending Renew and Rebind DHCPv6 messages when respective timers T1
and T2 expire. Rebind messages do not include a Server ID option and the
Rebind procedure ends when the last IPv6 address valid lifetime expires,
whereafter the client restarts the address acquisition procedure by
Soliciting for available servers.
See RFC 3315, sections 18.1.3. and 18.1.4. for details.
|
|
Provide a function to request more options from the DHCPv6 server.
Provide a sensible default set at startup and add test basic test
cases for the intended usage.
Define DNS and NTP related option codes and add comments for the
unassigned codes.
|
|
In order to keep the refcounting working, a DONT_DESTROY macro similar
to the one in sd-bus has been added also to DHCPv6.
|
|
|
|
|
|
client_initialize name is misleading, since the function is actually
useful at the *end*, to reinitialize the object. But reset is shorter,
so rename it to client_reset.
|
|
Receive and parse a Reply from the server. Set up T1 and T2 timers and
notify the library user of an acquired DHCPv6 lease.
|
|
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 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.
|
|
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 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.
|
|
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.
|
|
Add initial structure definition and functions for setting index, MAC
address, callback and event loop. Define protocol values and states.
|
