add hostsfile output in addition to statefile a92c0a7 made the temporary state/leasefile hidden so that an atomic change was made and dnsmasq only saw the new file on rename. A misguided optimisation was made to only rename the temporary file if something had changed. Unfortunately only address and hostnames were considered in the change, lease durations were not. As a result it was possible for LUCI which consumes the state/leasefile to report DHCPv6 leases had expired when they had not. Revert the optimisation so that the file rename occurs irrespective of content change, this keeps LUCI reporting of state/lease expiry correct. This leaves us back with hosts file/dnsmasq update problem. Solve this by writing out a separate hosts file. Update this file using the original IP/Hostname change logic that prompts calling the 'lease' script. odhcpd config now supports a string 'hostsfile' which defines the path and name of the hosts file in an identical manner to 'leasefile'. A state 'leasefile' must be defined IF a 'hostsfile' is also required. eg. leasefile '/tmp/odhcpdstate' hostsfile '/tmp/hosts/odhcpdhosts' Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
dhcpv4: improve error when a prefix is too long If a user tries to enable dhcpv4 on an interface with a /29, odhcp won't work. The logs will only contain a message that doesn't help identify the problem. It'd be idea to support any prefix with a valid pool, but at least this would point a confused user in the right direction. Signed-off-by: Ross Vandegrift <ross@kallisti.us>
odhcpd: add support for dhcpv6_pd_min_len parameter The dhcpv6_pd_min_len configuration clamps the requested prefix delegation to be at least as big as the option. This allows a router to manage the size of each downstream router's prefix delegation length independently from the delegating interface's prefix length. This behavior is an implementation choice permitted by the RFCs. The delegating router (us) is not required to honor the hint (RFC3633, section 11.2, we MAY choose to use the information in the option; RFC8168, section 3.2 has several SHOULDs about desired choices for selecting a prefix to delegate). This configuration allows us to conserve prefix space so that any single router can't grab too much of it. Consider if we have an interface with a /56 prefix. A requesting router could ask for a /58 and take 1/4 of our total address space. But if we set a minimum of /60, we can limit each requesting router to get only 1/16 of our total address space. sample config: config dhcp 'pd' ... option dhcpv6_pd_min_len '60' Signed-off-by: John Kohl <jtk.git@bostonpog.org> [ use different comment style and fix commit description ] Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
router: Add PREF64 (RFC 8781) support This option of IPv6 Router Advertisements allows devices connected to a IPv6-only network to discover IPv6 prefix of the NAT64 gateway. Devices can use this information for instance to setup client translator (CLAT) from IPv4 to IPv6 in 464XLAT (RFC 6877) scenario or to handle IPv4 address literal on application level. To enable PREF64 option, a new uci parameter ra_pref64 has to contain the NAT64 prefix, including prefix length. Only lengths of 96, 64, 56, 48, 40 and 32 bits are supported. For example, to annonce the Well-Known Prefix: config dhcp 'lan' … option ra_pref64 '64:ff9b::/96' Fixes: #182 Signed-off-by: Ondřej Caletka <ondrej@caletka.cz> [ remove extra space for Fixes tag ] Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
config: use dedicated link local function to check interface Use netlink_get_interface_addrs is wrong and doesn't actually work. The function checks only for UNIVERSE address and is not suitable for dumping linklocal address of an interface. Use the new and dedicated function to get interface linklocal address to correctly check if the interface can receive message. Fixes: #197 Fixes: 7c0f603abc14 ("router: skip RA and wait for LINK-LOCAL to be assigned") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
netlink: add support for getting interface linklocal Add support for getting interface linklocal address. This is needed to make sure an interface have a valid link local address and such address is not TENTATIVE. With these info we can check if an interface is ready to accept packets. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
config: fix feature for enabling service only when interface RUNNING With ba30afcfec0a26ce4bcd96ea4d687c498b0ba4df it was found that odhcpd service are setup even if an interface had no connection and was not running. The commit introduced the change but required more fixup for the feature to work correctly. The close_interface() remove the interface from the avl list and this cause the interface to be missing later in the code flow. The intention of the commit was to just disable the service and enable them later when the interface is correctly set to running with the flag IFF_RUNNING. Change the logic and introduce a new function reload_servies() that will check IFF_RUNNING and enable or disable odhcp services. This function is called on odhcpd_reload() for each interface. In odhcpd_reload() also restore the original pattern with calling close_interface() only when the interface is not inuse for odhcp. Also call reload_services() on the single interface when a RTM_NEWLINK event is fired reacting to a link change of an odhcp interface and enabling the services if IFF_RUNNING is set. Fixes ba30afcfec0a ("config: skip interface setup if interface not IFF_RUNNING") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
config: recheck have_link_local on interface reload if already init If an interface is already init in the odhcpd avl tables, have_link_local is not set to true with a link local addr set as get ipv6 addr is skipped. Move checking for have_link_local outside get_addr to better track when an interface is ready and have a link local addr for interface already init in odhcpd avl tables. Fixes: #197 Fixes: 7c0f603abc14 ("router: skip RA and wait for LINK-LOCAL to be assigned") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
router: skip RA and wait for LINK-LOCAL to be assigned This fix a specific and corner case when the following error and similar is printed in the log: Failed to send to ff02::1%br-lan (Address not available) The cause for this was tracked down to the lack of the interface of a configured LINK-LOCAL IPV6 address resulting in odhcpd_send() always failing. A LINK-LOCAL IPV6 address is assigned only after the interface has carrier and is set to IFF_RUNNING and require some time for the address to be assigned due to DAD logic. In the case where an interface was just UP, odhcpd RA may fail since the LINK-LOCAL IPV6 address still needs to be assigned as it still need to be "trained". From the kernel view this is flagged in the IPV6 interface address with the flag IFA_F_TENTATIVE, that means the address still needs to be checked and follow DAD process. This is only a transient problem and the DAD process is required only once till the interface is not set DOWN. To handle this, add some check to verify if the address has to be checked and add an additional bool to flag if the interface have a LINK-LOCAL assigned. Skip sending RA if the interface still doesn't have finished the DAD process and retry at the next RA. A notice log is added to track this special case to track problematic case and even more corner case. Logic to check if interface have LINK-LOCAL are: - When interface is setup, on scanning for the interface ipv6 address check if at least one address is NOT in IFA_F_TENTATIVE state. - With interface already up but with still no LINK-LOCAL react on the RTM_NEWADDR event and set LINK-LOCAL if the addrs added by the event is a LINK-LOCAL reflecting that the interface finally ended the DAD process and have a correct address. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Acked-by: Hans Dedecker <dedeckeh@gmail.com>
config: skip interface setup if interface not IFF_RUNNING We currently setup odhcp service even if the interface is not running. This is the case for bridge or specific interface that are flagged as UP but have no carrier as nothing is connected to it. This cause a similar error like: Failed to send to ff02::1%br-lan (Address not available) This is caused by the kernel assigning IPV6 address only when the interface is set to IFF_RUNNING. A LINK-LOCAL IPV6 address is required for odhcpd_send() to work or every request will be rejected. To fix this setup services only when interface is in IFF_RUNNING state. When an interface change state, odhcpd is reloaded and the services are correctly setup again. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Acked-by: Hans Dedecker <dedeckeh@gmail.com>
Revert "odhcpd: Reduce error messages" Silencing an error message without properly understanding why it occurs is terrible practice. "I think this would be better served as debug." doesn't inspire confidence the author actually understood what was going on, so revert this commit. This reverts commit 90d6cc9cd48a333b95604ff90f7ffe67fe14efe3. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
odhcpd: Reduce error messages When there's no network cable connected to LAN, then odhcpd does this: Tue Jan 24 18:32:04 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:20 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:36 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Tue Jan 24 18:32:52 2023 daemon.err odhcpd[2017]: Failed to send to ff02::1%lan@br-lan (Address not available) Accurate, but not very interesting. I think this would be better served as debug. Signed-off-by: Peter Naulls <peter@chocky.org>
router: always check ra_default We currently only check ra_default when an interface has valid addresses. This results in ra_default being ignored in case we have an interface with only link-local addresses. This effectively breaks the use of value 2 for the ra_default parameter. Fix this by always checking ra_lifetime, regardless of the interface having public addresses or not. Fixes: #11930 Fixes: 83e14f455817 ("router: advertise removed addresses as invalid in 3 consecutive RAs") Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be> Acked-by:Hans Dedecker <dedeckeh@gmail.com>
router: improve RA logging We only set the RA lifetime to what is configured in UCI when there is a default route and valid prefix. In any other case, we set it to 0. This leads to confusion where people believe ra_lifetime is completely ignored. In case there is a default route, but no valid prefix, a debug message explains this, but if there is no default route, we silently override ra_lifetime. Add a debug message for the latter case, and explicitly mention overriding ra_lifetime in both cases. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be> Acked-by: Hans Dedecker <dedeckeh@gmail.com>
dhcpv4: detect noarp interfaces Don't add ARP entries to interfaces with IFF_NOARP, it causes problems with for example WireGuard interfaces (which requires this change to be usable with DHCPv4-over-DHCPv6). Signed-off-by: Mikael Magnusson <mikma@users.sourceforge.net>
dhcpv6-ia: make tmp lease file hidden Use a hidden . prefixed temporary lease file instead of appending '.tmp'. Dnsmasq is capable of scanning files/directories using inotify to receive file change notifications and updating its view of hostname ip address mapping without being SIGHUPped. Until dnsmasq v2.88 this mechanism allows additions to hostnames, no deletions. dnsmasq v2.88 when released will understand how to remove mappings. Unfortunately without this change dnsmasq sees odhcpd's temporary lease file via inotify and it also sees the change when odhcpd atomically renames the file from '.tmp' to the correct name. dnsmasq excludes hidden '.' files from it's inotify scans, thus changing odhcpd to use a hidden temporary lease file reduces load and makes sense. Also, while here, only rename the temporary file if it actually contains different content. Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
odhcpd: Support for Option NTP and SNTP Support for DHCPv6 Option NTP (Option-56) and SNTP (Option-31), DHCP Option NTP(Option-42) is implemented. ntp list is supported for IPv4, IPv6 and FQDN. Signed-off-by: Avinash Tekumalla <avinash.tekumalla@technicolor.com> Signed-off-by: Alin Nastac <alin.nastac@technicolor.com> Signed-off-by: Ashutosh Shandilya <ashutosh.shandilya@technicolor.com> Signed-off-by: Vidya Rajagopal <vidya.rajagopal@technicolor.com>