NTP Time Will not Sync

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

CKNairb

New Around Here
Currently using 380.66_6 on a RT-AC87U, and i have always seen ( through multiple Firmware Revisions ) the notification in the system Tab of the Administration Settings that the NTP was not sync'd, causing the Auto Restart to happen at the wrong local time. i have tried the Default, Google's Public, and the Navy's NTP. none will get the time to Sync, currently the router thinks its August 1st 2015. the logs say Start NTP Update, but it doesn't do it ( because it still thinks its 2015 )

any help would be appreciated, including the last bit of the log

Code:
Aug  1 20:49:28 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=23.40.70.43 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=14404 DF PROTO=TCP SPT=56544 DPT=443 SEQ=3187376582 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402)
Aug  1 20:49:28 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=8.8.4.4 LEN=77 TOS=0x00 PREC=0x00 TTL=127 ID=28206 PROTO=UDP SPT=52118 DPT=53 LEN=57
Aug  1 20:49:28 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=8.8.4.4 LEN=67 TOS=0x00 PREC=0x00 TTL=127 ID=28205 PROTO=UDP SPT=55139 DPT=53 LEN=47
Aug  1 20:49:28 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=13.107.3.128 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=16620 DF PROTO=TCP SPT=56547 DPT=443 SEQ=407666933 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402)
Aug  1 20:49:28 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=13.107.5.88 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=4063 DF PROTO=TCP SPT=56548 DPT=443 SEQ=1598509175 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402)
Aug  1 20:49:29 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=65.55.44.109 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=25700 DF PROTO=TCP SPT=56550 DPT=443 SEQ=2291705852 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402)
Aug  1 20:49:31 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=8.8.8.8 LEN=75 TOS=0x00 PREC=0x00 TTL=127 ID=32486 PROTO=UDP SPT=50465 DPT=53 LEN=55
Aug  1 20:49:31 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=216.58.217.131 LEN=1378 TOS=0x00 PREC=0x00 TTL=127 ID=27457 DF PROTO=UDP SPT=50466 DPT=443 LEN=1358
Aug  1 20:49:35 ntp: start NTP update
Aug  1 20:49:38 ntp: start NTP update
Aug  1 20:49:39 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=8.8.8.8 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=32487 PROTO=UDP SPT=63276 DPT=53 LEN=40
Aug  1 20:49:39 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=8.8.8.8 LEN=62 TOS=0x00 PREC=0x00 TTL=127 ID=32488 PROTO=UDP SPT=58889 DPT=53 LEN=42
Aug  1 20:49:39 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=172.217.8.4 LEN=1378 TOS=0x00 PREC=0x00 TTL=127 ID=27689 DF PROTO=UDP SPT=58890 DPT=443 LEN=1358
Aug  1 20:49:39 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=172.217.8.4 LEN=1378 TOS=0x00 PREC=0x00 TTL=127 ID=27690 DF PROTO=UDP SPT=58890 DPT=443 LEN=1358
Aug  1 20:49:39 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=77.234.44.40 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=31637 DF PROTO=TCP SPT=56553 DPT=443 SEQ=1026460087 ACK=0 WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40103030801010402)
Aug  1 20:49:42 ntp: start NTP update
Aug  1 20:49:52 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=8.8.8.8 LEN=81 TOS=0x00 PREC=0x00 TTL=127 ID=32489 PROTO=UDP SPT=58290 DPT=53 LEN=61
Aug  1 20:49:52 kernel: ACCEPT IN=br0 OUT=eth0 SRC=192.168.1.149 DST=23.211.124.27 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=2858 DF PROTO=TCP SPT=56559 DPT=80 SEQ=3825427665 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B40103030301010402)
 

CKNairb

New Around Here
Noticed a new Firmware was out, updated to 380.67 , same thing, but router says its July 31st 2015
 

ColinTaylor

Part of the Furniture
What kind of internet connection do you have, cable modem?

What non-default changes have you made to the router, particularly WAN DNS settings?

Try using the IP address of an NTP server rather than its DNS name.

Is your router in a mode other than "router mode"?
 

CKNairb

New Around Here
Comcast Cable ( using an ARRIS SURFBoard SB6190 that i purchased myself, ( i do not rent a modem )

will try the NTP IP when i get home

its in router mode, not extended or the other modes ( dont remember what they are called )

i am using Google's Public DNS Servers ( 8.8.8.8 and 8.8.4.4 ) because Comcast's DNS sucks


What kind of internet connection do you have, cable modem?

What non-default changes have you made to the router, particularly WAN DNS settings?

Try using the IP address of an NTP server rather than its DNS name.

Is your router in a mode other than "router mode"?
 

CooCooCaChoo

Senior Member
I believe the version of ntp that runs in the 66/67 firmware needs a minor workaround to function. The problem is that this version of ntp requires ntp.conf to be located in /etc directory, and the problem arises because /etc gets restored to firmware defaults which doesn't include ntp.conf. So every time it reboots, ntp.conf gets erased and the ntp daemon has no ntp servers to connect to and fails.

The workaround is to create the ntp.conf file with servers in the /jffs directory and have the init-services script copy the ntp.conf file from /jffs over to /etc and then start the ntp daemon ntpd.

ntp.conf file contents:

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

init-services file contents:

...
cp /jffs/(location)/ntp.conf /etc/ntp.conf
ntpd
...

And you will be set.
 

ColinTaylor

Part of the Furniture
I believe the version of ntp that runs in the 66/67 firmware needs a minor workaround to function.
That's very strange. Has this bug been reported elsewhere. I find it surprising that there aren't lots of people complaining about this. :confused:

What you are describing is the config file for the ntpd server that was added for parity with John's fork in 380.65. Are you confusing the client with the server?
 

RMerlin

Asuswrt-Merlin dev
I believe the version of ntp that runs in the 66/67 firmware needs a minor workaround to function. The problem is that this version of ntp requires ntp.conf to be located in /etc directory

The ntp client used by Asuswrt does not support any config file.
 

CKNairb

New Around Here
its Syncing now.

no idea why, but when i opened a browser and went to the NTP IP ( instead of the DNS address, i just typed the IP to confirm ) i was sent to a Comcast Activation screen ( was the first time ever seeing that, any other address would work normally ), did it, and after the modem restarted, i went to the Router and it is showing the correct date and time

*Edit - and the NTP address in AsusMerlin was not changed it is still Pool.ntp.org, the only change was going to the NTP via IP address, going to the DNS resolved name would work normally with no comcast activation

i thank you for all your help
 

RMerlin

Asuswrt-Merlin dev
no idea why, but when i opened a browser and went to the NTP IP ( instead of the DNS address, i just typed the IP to confirm ) i was sent to a Comcast Activation screen ( was the first time ever seeing that, any other address would work normally ), did it, and after the modem restarted, i went to the Router and it is showing the correct date and time

I wish ISPs stopped trying to be "creative", and just did what they are being paid to do, which is to route Internet traffic.. DNS hijacking, transparent web caching, undocumented port blocking, traffic throttling, speed boosters... These can all cause huge waste of time from customers trying to do anything beyond post cat videos on Facebook. And of course their tech support reps are often so poorly trained that they don't even know about these fancy things their netops have devised to "provide customers with a better experience", so if one of those "bright" ideas happens to be causing a problem to a customer, they aren't even skilled enough to diagnose the cause of the customer's problem...

This is only one of the things that the "net neutrality" debate is about.
 

FreshJR

Very Senior Member
The ntp client used by Asuswrt does not support any config file.

Correct me if I am wrong.

The ntp client used by ASUS does not use any config file but it does load variables (config of sorts) from NVRAM.

This NVRAM variable could be defined in Administration -> System -> NTP Server.
There is also another ??backup?? ntp variable in NVRAM under ntp_server1. This other variable is non configurable in webUI, unless I have it present from an older firmware installation and it is depreciated now.

While ASUS has its own ntp client, your busybox installation came with an additional ntpd executable that can be run as both a client and server.
This ntpd verion, from busybox, does look for settings within /etc/ntp.conf for a config, which would have to be copied over from JFFS as CooCoo has stated.

The reason I am clarifying this is because I am in the process of setting up the router to act as an NTP server for some devices on my network that are not allowed to access WAN, such as IP Cameras and my NAS, to give them a correct time.

Is there a reason to keep ASUS's, arguably less secure NTP client instead of the busybox version? I read there was a hijack for insecure NTP clients to have them act as a botnet. Not sure if ASUS did patch this issue.

Location of ntp related files is as follows:
ntpd symlinked from /usr/sbin (Busybox version) and launched from/bin/busybox*
ntpclient launched from /usr/sbin
ntp symlinked from /sbin and launched from /sbin/rc*
 
Last edited:

RMerlin

Asuswrt-Merlin dev
The ntp client used by ASUS does not use any config file but it does load variables (config of sorts) from NVRAM.

It doesn't. All arguments are passed through the command line. The only nvram settings ntpclient will interact with is ntp_ready (which it will set once ntp sync is successful), and another nvram setting that is mostly used at factory time (AFAIK).

Is there a reason to keep ASUS's, arguably less secure NTP client instead of the busybox version?

Most likely so it can better integrate with the firmware (for instance, taking care of setting ntp_ready once time has been set). It's also possible that at the time this was originally written, the busybox ntpclient was problematic. I've never looked at the ntpclient code before, so I wouldn't know if there was any other technical reason to do so.
 

FreshJR

Very Senior Member
It doesn't. All arguments are passed through the command line. The only nvram settings ntpclient will interact with is ntp_ready (which it will set once ntp sync is successful), and another nvram setting that is mostly used at factory time (AFAIK).



Most likely so it can better integrate with the firmware (for instance, taking care of setting ntp_ready once time has been set). It's also possible that at the time this was originally written, the busybox ntpclient was problematic. I've never looked at the ntpclient code before, so I wouldn't know if there was any other technical reason to do so.

Makes perfect sense.

Even if asus's npt client executable does not directly read the NVRAM variable itself, the command line executing the ntp client does have read the variable before passing it over.

So in a sense that loan nvram variable is the entire config file for asus's ntp client.

Also glad since it only executes a time sync from a script and non continuously, the chance for malicious botnet injection is low.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top