I've recently installed 22.03.0 on two ath79/unifiac APs. The Unifi AC Lite and Unifi AC Mesh. I migrated the config from 21.02. The config is basically the "dumb AP" setup with an additional guest SSID tied to a VLAN. It's set to IPv6-only for DHCP, and runs without an IPv4 address.
First, the clock changes on reboot. I sync to my NTP server in luci and it shows the current date. On reboot, the clock changes back to 2022-09-06 at the same time of day each time. I have to manually sync after each boot. I suspect it's not writing the system clock to RTC. Both units do this.
Second, it's requesting two fresh primary IP addresses on startup over DHCPv6 (not including temporary or link local addresses). It's confusing my main DHCP server because it's trying to assign two addresses the same DDNS hostname and PTR. On reboot, it requests two totally new addresses. It's not using the existing lease. Again, this occurs on both units. No other device on my LAN is requesting multiple addresses or changing IP on each boot.
My DHCP logs also shows they both occasionally getting into a state where they continuously renew the DHCP release multiple times per second. The units become unresponsive and I need to power cycle them.
Neither of your devices has an RTC to begin with, let alone a battery backed RTC. In order to get the least broken time in the absence of knowing what that would be, the time is set to the timestamp of the most recently changed file under /etc/, until ntp kicks in.
No RTC makes sense. On reboot I can see ntpd running, but it won't sync until I do it manually. I'll leave it out of sync overnight and see if it eventually happens. I would have thought it would do it immediately on boot, especially without an RTC.
My main router/DHCP/DNS server is also an NTP server. I've got a GPS/PPS hooked up and everything. It can sync even without internet. I wonder if it's one of those things where it's waiting for (disabled) IPv4 before attempting. I've seen that before. It could also be waiting for a "wan" interface which isn't a thing on a dumb AP either.
Anyway, I think I just figured out the DHCP issue. I have two interfaces (br-lan and br-guest) which had "Client ID when requesting DHCP" (DUID) set to a blank string. When I looked in the server logs, both interfaces generated the same DUID so each time one renewed a lease, the DHCP server would delete the other. The interfaces are on different subnets. Hence, a new IP address on every renewal. I manually defined a different DUID on the br-guest interface and it's now behaving. I think I'll give it a reboot or two to be sure.
Check that your APs themselves have internet access (ping/ wget), this entails having standard gateway and DNS set. Your connected clients don't need that, but ntp on your APs does.
ping, traceroute and nslookup to openwrt.org all work from the diagnostic page (on IPv6).
I think it's working now anyway. I've seen them NTP sync after reboot a couple of times.
The duplicate DUID did such a job on my DHCP tables that it caused isc-dhcp-server6 to segfault whenever I rebooted an AP. I just hosed out the leases cache along with DDNS on bind9. What a mess.
It looks like it's all working now. Thanks for your help everyone! Much appreciated.
I marked the manual DUID as the solution, but the NTP issue remains. I think I mistook a setting change followed by a reboot as a fix (which would have bumped the timestamp forward by touching a file). I might have to try IPv4 on it one day and see if that's the difference.