odhcpd: Replace strerror(errno) with %m format Saves a few bytes. Signed-off-by: Rosen Penev <rosenp@gmail.com>
dhcpv6: fix compile issues when CER-ID extension is enabled Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
treewide: rework handling of netlink events Rework the handling of netlink events by letting the different modules ndp, ra, dhcpv6 and dhcpv4 install netevent handlers. The installed netevent handlers are called by the netlink logic passing an event indication together with event data. Each netevent handler implements its own event logic; this makes the code more modular and less complex by moving all netlink code to netlink.c While at it rename ia_addr and ia_addr_len into addr6 and addr6_len respectively Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
treewide: align function naming Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
treewide: replace RELAYD prefix naming in macros Remove the unfortunate RELAYD naming in the different macros Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
treewide: rework logic to retrieve IPv6 interface addresses Retrieve IPv6 interface addresses when the interface gets created; this allows to get rid of the IPv6 address dump logic in ndp.c. Add IPv4 address support in odhcp_ipaddr struct. Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
treewide: rework code to get rid of fixed IPv6 address arrays Rework code to get rid of RELAYD_MAX_PREFIXES and RELAYD_MAX_ADDRS by using dynamic IPv6 address array allocation. Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
rework IPv6 dns address selection (FS#635) Don't return anymore the link local IPv6 address as DNS IPv6 address since different OS implementations (e.g. android, ...) cannot handle a link local IPv6 address as DNS address. IPv6 DNS address selection is reworked as follows : -Consider all global/ULA IPv6 address having a valid lifetime -Give preference to global/ULA IPv6 addresses being not deprecated -Give preference to ULA IPv6 addresses over IPv6 global addresses -Give preference to the IPv6 address with the longest preferred lifetime in its selected category (ULA or global) -If no global/ULA IPv6 address is present use the IPv6 link local address Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
rework IPv6 address dump logic Make the code more logical by moving the IPv6 address dump logic into the different protocol interface enable handlers so it's clear which protocols require interface IPv6 address tracking. At the same time restructure the IPv6 address dump logic so less IPv6 address netlink dumps are created. Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
router: add syslog debug tracing for trouble shooting Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
router/dhcpv6: use link-local addresses for DNS
dhcpv6: fix socket generation on relay master
dhcpv6: send relay-forward messages using correct socket
Fix IPv6 DNS server adddress selection Fix selection of IPv6 DNS address in DHCPv6 and RA overwrite as an address could be selected with preferred lifetime zero while IPv6 addresses are in use with non zero preferred lifetimes. Fix tries to pick the IPv6 address with the longest preferred lifetime now. Fixes also the issue an IPv6 address with preferred lifetime zero could be returned in DHCPv6 DNS server option while an IPv6 address with non zero preferred lifetime is returned as DNS recursive RA option for the same set of available IPv6 addresses.
Replace option sol_max_rt by inf_max_rt in reply response to information request
DHCPv6 destination address check As described in RFC3315 §15 any solicit, confirm, rebind or information request message is discarded if the destination address is unicast Likewise any request (§18.2.1), renew (§18.2.3), release (§18.2.6) or decline (§18.2.7) message is discarded and the server replies with the status code use multicast.
Fix DHCPv6 relay reply message in case raw DHCPv6 attributes are present Use enum to index iov struct
Make filtering customizable
Add support for raw DHCPv6 attributes
Don't return a DHCPv6 reply in response to a confirm without address(es) RFC3315 Section 18.2.2 states no reply must returned by the server in case no address(es) are present : If the server is unable to perform this test (for example, the server does not have information about prefixes on the link to which the client is connected), or there were no addresses in any of the IAs sent by the client, the server MUST NOT send a reply to the client.