Upgraded from 23.05.3 to 23.05.5. Before, it showed the correct date and time. Since the upgrade, it shows 2024-09-23 14... onwards here; I guess build-time.
It is well connected to the Internet, and "Sync with NTP server" doesn't help either. Despite of me having pressed that key several times, the System Log also shows no traces of some date/time adjustment.
Since I didn't do any modifications at update, just the automatic restart, and since it was correct before the update/reboot, I wonder if some mistake has happened?
openwrt-23.05.5-ath79-generic-engenius_eap600-squashfs-sysupgrade.bin
is the file used for the update.
The setting is four times openwrt.pool.ntp.org., and the sites can be pinged.
Does it match your setup (dumb AP-like)? If so, there seems to be a bug with sysntpd where it deadlocks, if it fails to resolve all of the hostnames on startup.
In that case, either delaying sysntpd enough or switching to raw IP addresses for NTP servers "fix" the issue.
Yep. "Fixes" the issue. 178.215.228.24 as sole NTPd immediately brings the correct time. The problem is the name resolver. 'ping' under Diagnostics also fails to resolve FQDNs.
I could ssh into it, and confirm that it doesn't resolve any names. In the (GUI) settings, the correct DNSes are set (including 8.8.8.8).
$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enx6c0b84228891)
Current Scopes: none
Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 3 (wlp6s0)
Current Scopes: DNS
Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.100.1
DNS Servers: 192.168.100.1 8.8.8.8
DNS Domain: lan
192.168.100.1 is okay, as I can see from another client:
while $ dig @192.168.100.1 google.com
resolves.
(200 is the OpenWRT box).
Almost worse: I found that it fails to dish out/renew DHCP addresses. With ssh I could see 1604 root 1744 S /usr/sbin/odhcpd
Should this be okay for dhcpd to work?
Honestly speaking, this is quite a letdown. Honestly, I haven't done anything else than the basic update procedure, not touched a single setting.
Thanks also for your hint; but I'm not deep enough into this matter to understand what I could be doing, and where.
Being an old Unix-guy: couldn't we just write the proper servers into /etc/resolv.conf? (I never ever liked that systemd-stuff)
Could the DHCPd problems be related? ("No dhcpd without name resolution"?)
I did have a discussion here, earlier, if an AP should do DHCP. In any case, here it is needed.
Thanks for the clarification.
I have gone through the available, standard, logs. No errors, not even a warning.
Next, I shut down the dhcpd on said box, and activated a most basic, if not to say 'stupid' one on a cheap commercial box. Immediately everything works once again, since that dhcpd dishes out IPv4 addresses, and points to a functional resolver. Whioch is the one and the same that OpenWRT professes to use for name resolution (192.168.100.1)
Though I'd prefer to go back to OpenWRT. That other dhcpd doesn't even allow to set static IP addresses to MAC addresses.
Should I dare a cold boot? But I don't see any good reason to expect a different behaviour.
Only for completeness: flashing back to 23.05.3, keeping the configuration, results in a fully functional system once again.
Maybe you would want to try similar? (Your posting was dated July 26, well beyond the release of 23.05.3
No, that was right after 23.05.4 (that's what the device in question is running). And the OP with the issue dates back to April/2023 (pre-23.05.3), it's not a new bug either.
Let’s take a look at your configuration to see if there are any errors:
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
