After spending an embarrassingly long time tracking down why some of my clients couldn't renew their IP addresses I realized that the authoritative flag wasn't set on odhcp running in ipv4 + ipv6 mode. It turns out with that flag unset the server MUST stay silent when a client tries to renew an IP that isn't in the server's cache. With the flag set the server is allowed to NAK the transaction and then start over with a fresh assignment that it will put in the cache. The assignment will usually be exactly the same IP address that the client requested. The difference is that in authoritative mode the server is allowed to resync things. Without it it MUST continue to ignore the renewal request.
The rub is that in OpenWRT the cache is never persistent across reboots. I tried to put the odhcpd cache file into persistent memory but that did nothing. The file was actively cleared by odhcpd when it started up.
It strikes me that the authoritative flag should be forced to be true in openwrt. I don't see how it can ever work correctly in the face of reboots.
Perhaps something changed in the DHCP logic that previously dealt with this case. Perhaps my flag got lost on one of the upgrades. My clients only lost their IPv4 addresses after the 25.12.xx upgrade.
Can anyone shed more light on this? Am I analyzing things correctly?
By default, odhcpd is exclusively used for IPv6, so there must have been substantial package & config changes by you, if odhcpd was acting as dhcpd for IPv4 instead of dnsmasq.
There are two packages in the openwrt repository. One called "odhcpd-ipv6only" and another one called just "odhcpd". What I'm talking about here is a bug in how the protocol under non-authoritative operation works with a server that doesn't preserve a cache across reboots. The client asks to renew the lease and the server can't find the lease in the cleared cache and in the non-authoritative mode in order to comply with the ipv4 dhcp protocol must not reply at all.
There have been major changes to odhcpd and how DHCP works in OpenWrt in general, between late last year and early this year. Some for the good, some less beneficial. So, a possible start into troubleshooting would be to first figure out whether this worked properly at some time or not, and if it worked before, to figure out which commit broke it, if any.
(if your clients are also OpenWrt) it might be related to OpenWrt now sending DHCPv4 option 61 (Client ID) for identifying a client, instead of relying on the MAC address, and in addition, the option isn't populated with "0x01" followed by the MAC address (default), but by an arbitrarily generated UUID that is generated on sysupgrade if it didn't exist before.
Do a forum and OpenWrt issue tracker search, there have been numerous complaints and workarounds.