| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Add a helper function containing a modified version of dns_packet_read_name()
that does not use DnsPacket to extract a string array of domain names from
the provided option data. The domain names are stored uncompressed as defined
in Section 8. of RFC 3315.
|
|
Add a helper function that extracts a block of IPv6 addresses from
the provided option data.
|
|
- Rename log_meta() → log_internal(), to follow naming scheme of most
other log functions that are usually invoked through macros, but never
directly.
- Rename log_info_object() to log_object_info(), simply because the
object should be before any other parameters, to follow OO-style
programming style.
|
|
log_error_errno() as log calls that take error numbers
This change has two benefits:
- The format string %m will now resolve to the specified error (or to
errno if the specified error is 0. This allows getting rid of a ton of
strerror() invocations, a function that is not thread-safe.
- The specified error can be passed to the journal in the ERRNO= field.
Now of course, we just need somebody to convert all cases of this:
log_error("Something happened: %s", strerror(-r));
into thus:
log_error_errno(-r, "Something happened: %m");
|
|
With this change the DHCP6_OPTION_IAADDR_LEN define can be removed in
favor of using sizeof(). Using the name of the struct and sizeof()
makes it clearer how much and what data is being copied from the
DHCPv6 message.
|
|
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.
|
|
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.
|
|
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.]
|
|
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.
|
