Kaspar Schleiser [Wed, 12 Feb 2014 12:48:25 +0000 (13:48 +0100)]
use enum to specify order and indexes of iov struct.
This helps to avoid brainfuck index calculation errors when adding
features.
On my build machine (arch linux x86_64), the stripped binary has exactly
the same size, so this patch should produce the same binary, but
increase code maintainability.
previously, only option 56 (NTP server) was supported, but named SNTP_*
throughout code and in the scripts environment. This patch fixes this and adds
optnion 31 (SNTP Servers) support. Uses NTP_IP and NTP_FQDN and SNTP_IP in
script environment.
Contributed by T-Labs, Deutsche Telekom Innovation Laboratories
Avoid several race conditions by using distinct variables for the different
signals. In particular different signals received in quick succession don't
overwrite each other any more, and odhcp6c_signal_process doesn't return true
anymore when a new SIGIO is received while another is still being processed.
Use getifaddrs to get the interface-id when not specified
Reimplementing this section also fixes two potential bugs:
1. Only link-local addresses should be used for automatic interface-id
selection, as it should always be assigned by the kernel and is always based
on the EUI-64 unless an administrator is doing strange things (while other
addresses might be chosen according to the privacy extensions or by an
administrator)
2. When no address is available (because of a race condition or because an
administrator removed it), RA packets should just be ignored; otherwise
an address with a zero interface-id might be assigned
Hans Dedecker [Sun, 1 Dec 2013 17:57:06 +0000 (18:57 +0100)]
Fine tune server candidate selection logic
DHCPv6 server info from ADVERTISE messages is inserted in the server
candidate list sorted according to the preference value (highest values
first in the list).
Server candidate list can only contain one entry from a given server.
Server with highest preference value is selected; in case the server
does not respond the next server is selected from the list.
When the server candidate list is empty and no servers responded;
the client restarts the DHCPv6 server discovery process
Hans Dedecker [Wed, 23 Oct 2013 12:04:38 +0000 (12:04 +0000)]
odhpc6c: status code support in reply
The patch implements support for status code handling in
reply messages as described in RFC3313 paragraph 18.1.8.
The client will
*log the status codes returned by the client
*send a request if no binding status code is returned for
a given IA
*send further renew/rebind if the IA was not present in
the reply
*terminate message exchange when no prefix/no address
status code is returned in reponse to a request
*terminate message exchange when unspec fail status code
is returned
*calculate t1/t2/t3 when all IA's have been processed and
based on recorded t1/t2/valid timer values per IA
Without this patch I have seen issues with request messages
send without any IA_PD/IA_NA and t1/t2/t3 timer values which
were not correct. These changes have been tested intensive
against an ISC DHCPv6 server
Signed-off-by: Hans Dedecker <hans.dedecker@gmail.com>
Hans Dedecker [Wed, 23 Oct 2013 12:04:27 +0000 (12:04 +0000)]
odhcp6c: preference and status code support in advertise
The patch implements handling of advertise messages
as described in RFC3315 paragraph 17.1.2. Client will
stop collecting advertise messages if preference option
is equal to 255 or if the first RT has elapsed. Status
codes are handled in the advertise message depending on
the startup parameters
Signed-off-by: Hans Dedecker <hans.dedecker@gmail.com>
Hans Dedecker [Wed, 23 Oct 2013 12:04:01 +0000 (12:04 +0000)]
odhcp6c: message retransmission count support
The patch implements message retransmission count (MRC) support as
described in RFC3315 paragraphs 5.5 and 14 for DHCPv6 request/release/
decline messages. Patch also disables multicast packets loopback.
Signed-off-by: Hans Dedecker <hans.dedecker@gmail.com>