[inetquestion]

Observed this was broken on build 43334, had to go all the way back to build 42681 to get NTP working again. Is this already on the radar to be fixed?

Did some wolf fencing with the versions and found it broke between these builds:

03-13-2020-r42681 (NTP Working)
...
04-10-2020-r42872 (NTP Broken)


Btw: This was on: Linksys WRT3200ACM


-Inet

[egc]

A lot of things depend on an accurate time so if it was really broken there would have been more reports.

It could be for your specific router type or your specific setup.

So enlighten us with your specific setup and syslog messages

NTP works best if you leave it blank

[inetquestion]

Sorry, this is on a Linksys ACM3200..

I dont have access to the syslog where it is broken now that I'm on a different working version, but can goto a broken version to get them again if this helps. While it was broken, tried several NTP servers (google, Nist, apple)... After all those failed, started going back versions to find a working one.

Originally found this issue reported on redit while looking for a fix:

https://www.reddit.com/r/DDWRT/comments/gfjwll/ntp_issues_with_recent_version/

[egc]

That poster mentions and R6400v1, I have one running usually upgrading when a new build arrives and have never had any problem.
But like I said, ntp works best if you use the built-in time server (so leave it blank).

So it can be something in your specific setup, I have seen some reports, if the router is setup as a bridge and local DNS and Gateway were not setup correctly and the WAN was not disabled that the router did not get the right time.

So therefore it helps if we know your specific setup

[inetquestion]

Going to latest version, still fails with any user specified server. As you mentioned, it works leaving it blank. Leaving it blank is a work around, but something is actually broken if you cannot specify an NTP server. Will leave on this version for now if you would like additional debug info.


===Using build 43334 with NTP server: time.google.com (same result with other user specified servers)

Dec 31 19:01:03 apu-3200 daemon.err ntpclient[1681]: Failed resolving address to hostname time.google.com: Try again
Dec 31 19:01:03 apu-3200 daemon.err ntpclient[1681]: Failed resolving server time.google.com: Network is down
Dec 31 19:01:03 apu-3200 daemon.err process_monitor[1680]: cyclic NTP Update failed (servers time.google.com)
Dec 31 19:01:03 apu-3200 daemon.err process_monitor[1680]: Last update failed, we need to re-update after 30 seconds


===Using build 43334 with NTP server: <blank>
Dec 31 19:06:35 apu-3200 daemon.notice ntpclient[2405]: Network up, resolved address to hostname 212.18.3.19
Dec 31 19:06:35 apu-3200 daemon.debug ntpclient[2405]: Connecting to 212.18.3.19 [212.18.3.19] ...
Jun 8 10:39:22 apu-3200 daemon.info ntpclient[2405]: Time set from 212.18.3.19 [212.18.3.19].

[egc]

Thanks I will look into, will run some tests also and make a bug report if necessary.

[kernel-panic69]

I'm about to reset my R9000 and re-configure client bridged (routed) from scratch again to test it. Not sure why it's balking on correct time with no user-specified NTP server.

[egc]

I have set a time server nearby and this one works:

[kernel-panic69]

On r43334, R9000, client bridged mode; process_monitor is not starting up. I have not checked in default configuration out-of-the-box. I had to add sleep 10; restart process monitor to my startup script for it to work and NTP to update with a blank server entry. I guess both issues need to be looked into.

[inetquestion]

Seems this may be more specific to 3200ACM, as others have reported the issue with that model specifically. What additional information would you like to see to dig further?

With no server specified, I'm still seeing these occasionally. Shortly thereafter it starts working. There are other machines behind this router which also use the same NTP servers and those are working without issue.

Jun 8 12:39:31 apu-3200 daemon.err ntpclient[3337]: Failed resolving address to hostname 2.pool.ntp.org: Try again
Jun 8 12:39:31 apu-3200 daemon.err ntpclient[3337]: Failed resolving server 2.pool.ntp.org: Network is down
Jun 8 12:39:31 apu-3200 daemon.notice ntpclient[3337]: Network up, resolved address to hostname 212.18.3.19
Jun 8 12:39:31 apu-3200 daemon.debug ntpclient[3337]: Connecting to 212.18.3.19 [212.18.3.19] ...
Jun 8 12:39:30 apu-3200 daemon.info ntpclient[3337]: Time set from 212.18.3.19 [212.18.3.19].
Jun 8 12:39:30 apu-3200 daemon.info process_monitor[2560]: cyclic NTP Update success (servers 2.pool.ntp.org 212.18.3.19 88.99.174.22)

[kernel-panic69]

The builds you are initially referring to might be during dnsmasq updates that may have resulted in DNS resolution issues - and DNS resolution issues aren't necessarily that something is "broken", per se. I've had those messages before, but NTP wasn't "broken". The situation I am referring to on my R9000 is the time is completely wrong, like it half-ass syncs to an 18:00 time, no matter what time of day or night it is.

I'm more curious about how your 3200 is configured, specifically DNS/dnsmasq. I only have one set of the failed resolving messages prior to NTP update on my E4200v1. I don't have my R7800 up at the moment, nor my R7000P, for comparison.

[inetquestion]

Settings attached...

[Mile-Lile]

[egc]

Indeed, "Use DNSMAsq for DNS" is disabled that might explain it?

[inetquestion]

Thank you for the investigation, recommendations, and clarification. Enabled dnsmasq and am able to specify a time server accordingly without any issues.

Admittedly only come here when experiencing a problem, curious if there is a sticky for recommended best practices for setup/config in one place? found this one, but asking if there is a more comprehensive set...

https://wiki.dd-wrt.com/wiki/index.php/Basic_Wireless_Settings

Thanks again!