| Age | Commit message (Collapse) | Author |
|---|
|
Let's settle on a single type for all address family values, even if
UNIX is very inconsitent on the precise type otherwise. Given that
socket() is the primary entrypoint for the sockets API, and that uses
"int", and "int" is relatively simple and generic, we settle on "int"
for this.
|
|
arrays
As long as the number of array entries is relatively small it's nicer to
simply return the number of entries directly, instead of using a size_t*
return parameter for it.
|
|
It appears there is no good way to decide whether or not broadcasts should be enabled,
there is hardware that must have broadcast, and there are networks that only allow
unicast. So we give up and make this configurable.
By default, unicast is used, but if the kernel were to inform us abotu certain
interfaces requiring broadcast, we could change this to opt-in by default in
those cases.
|
|
It complains about optoffset possibly being uninitialized. It is wrong,
but let's just initialize it.
|
|
It complains about {max,init}_retransmit_time possibly being
uninitialized. It is wrong, but let's just initialize it.
|
|
Vendor Class Identifier be used by DHCP clients to identify
their vendor type and configuration. When using this option,
vendors can define their own specific identifier values, such
as to convey a particular hardware or operating system
configuration or other identifying information.
Vendor-specified DHCP options—features that let administrators assign
separate options to clients with similar configuration requirements.
For example, if DHCP-aware clients for example we want to separate
different gateway and option for different set of people
(dev/test/hr/finance) in a org or devices for example web/database
servers or let's say in a embedded device etc and require a different
default gateway or DNS server than the rest of clients.
|
|
Reading BPF assembly written as C macros is inherently difficult. Don't
make it harder than necessary and provide clearer explanation in the
comment.
|
|
We already ignore IP fragments, because we expect that Fragment
offset (FO) field is not set. However first fragment in a fragmented IP
flow will have all zeroes in FO field. We should ignore such packet as
well, thus we need to look at MF flag in the IP header. Checking MF flag
will filter out all except last packet in fragmented flows. Last one
will be ruled out by next check for value of FO.
|
|
Check that received DHCP packets actually include our MAC address in
chaddr field. BPF interpreter has 32 bit wide registers but MAC address
is 48 bits long so we have to do check in two steps.
|
|
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
|
|
Send hostname (option 12) in DISCOVER and REQUEST messages so the
DHCP server could use it to register with dynamic DNS and such.
To opt-out of this behaviour set SendHostname to false in [DHCP]
section of .network file
[tomegun: rebased, made sure a failing set_hostname is a noop and moved
config from DHCPv4 to DHCP]
|
|
|
|
|
|
strndup need to be chcked
|
|
Even if we cannot renew the lease at T1, we will likely succeed at T2, so warn and ignore the failure.
This could happen if for whatever reason the received address is not yet configured, or it has
been lost.
|
|
This adds support for DHCP options 33 and 121: Static Route and
Classless Static Route. To enable this feature, set UseRoutes=true
in .network file. Returned routes are added to the routing table.
|
|
Note that /proc/sys/net/ipv4/ip_dynaddr needs to be non-zero.
[tomegun: hook up DHCP renew events to increase the lifetime when necessary]
|
|
|
|
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.
|
|
Create a helper function to compute the remaining time in seconds from
time T2 to the IPv6 address with the longest lifetime. The computed
time is used as the Maximum Retransmission Duration in Rebinding state.
See RFC 3315, section 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 some use cases stopping an ongoing ICMPv6 discovery is more
useful than always unreferencing the whole structure.
|
|
In order to keep the refcounting working, a DONT_DESTROY macro similar
to the one in sd-bus has been added also to DHCPv6.
|
|
|
|
Let's keep this behavior consistent across our libraries.
In order to keep the refcounting working, a DONT_DESTROY macro similar
to the one in sd-bus was introduced.
|
|
|
|
The short lease was useful for testing, but in real-world usage it is pointless to keep leases
this short. That said, the cost of lease renewal is really low, so we keep the lease still
relatively short at one hour to not get into hard-to-hit problems with lease exhaustion etc.
|
|
The destination IP address should be INADDR_BROADCAST, but was
accidentally left as INADDR_ANY.
|
|
Removes _cleanup_dhcp_lease_free_. While the automatic cleanup
functions are great to have this one is never used and causes
a warning in clang.
|
|
Don't close the fd given to sd-icmp6-nd, since it will be aynschonously closed
by sd_icmp6_nd_unref
|
|
|
|
|
|
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.
|
|
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.
|
