RT-ac68u wont sync NTP v. 378.56

[R1-Limited]

Seems something is stuck. tried multiple NTP servers, my Media Bridged RT-ac66u is fine same NTP same build. Started after I updated to .56


Jul 31 17:04:06 hour monitor: ntp is not syn
Jul 31 17:04:36 hour monitor: daemon is starting
Jul 31 17:04:36 hour monitor: ntp is not syn
Jul 31 17:05:06 hour monitor: daemon is starting
Jul 31 17:05:06 hour monitor: ntp is not syn

 

[R1-Limited]

** Rolled back to .53 IMO more stable.
Reason #1 Media Bridge aint broke (Yes I know Asus)
Reason #2 NTP on the 68
Reason #3 seems .53 runs with no issues for me.

 

[Blinkyz]

Seems something is stuck. tried multiple NTP servers, my Media Bridged RT-ac66u is fine same NTP same build. Started after I updated to .56


Jul 31 17:04:06 hour monitor: ntp is not syn
Jul 31 17:04:36 hour monitor: daemon is starting
Jul 31 17:04:36 hour monitor: ntp is not syn
Jul 31 17:05:06 hour monitor: daemon is starting
Jul 31 17:05:06 hour monitor: ntp is not syn

Same issue since .56.No VPN or something on, only a simple vanilla config
Sticking with .55,waiting for something stable

 

[john9527]

Can someone with this issue please try the following for diagnostics purposes....

telent/ssh to the router and enter

nvram get link_internet
If it returns a value other than 2 then

nvram set link_internet=2
service restart_ntpc

and see if it frees up (this may or may not help, or only be a temporary fix)

 

[R1-Limited]

I will do this after work, I work from home. I will updtae back to 56 and see

 

[RMerlin]

What type of WAN connection do you have?

 

[R1-Limited]

Cable PPPOE set to Auto in the router

 

[RMerlin]

Could you try disabling the DHCP+VPN option at the bottom of the WAN page to see if it helps?

Also make sure you have the router set to automatically obtain an IP (again on that same page).

 

[R1-Limited]

There is not Wan + VPN on the WAN page of the 68u

 

[R1-Limited]

Can someone with this issue please try the following for diagnostics purposes....

telent/ssh to the router and enter

nvram get link_internet
If it returns a value other than 2 then

nvram set link_internet=2
service restart_ntpc

and see if it frees up (this may or may not help, or only be a temporary fix)

This worked
Cool

Now if only the damn Media Bridge would stay connected

 

[john9527]

This worked
Cool

Now if only the damn Media Bridge would stay connected

Cool....this confirms the 'what'....for some reason the check that the dns services are up and running is failing.
Now to figure out the 'why'.....

If you would like to continue to help debug, can you reboot (it will wipe out the changes you made) then make the syslog available? You can PM me with a location for the syslog if you prefer.

 

[ancelotti]

Mine wouldn't synchronize until I fixed the DST start/end date. If you're in North America is should start 3 month, 2nd Sunday, 2 hour...and end on ..11 month, 1st Sun, 2 hour.

I've noticed it wasn't set correctly for this region by default.

 

[RMerlin]

Cool....this confirms the 'what'....for some reason the check that the dns services are up and running is failing.
Now to figure out the 'why'.....

If you would like to continue to help debug, can you reboot (it will wipe out the changes you made) then make the syslog available? You can PM me with a location for the syslog if you prefer.

One of the changes in GPL 7838 is ntp.c checks for link_internet being 2 instead of 1.

From what I can see, link_internet will be set to 2 if the router is able to succesfully resolve some specific hosts (such as www.google.com) in do_dns_detect(), or 1 if it fails. I suspect part of the problem is do_dns_check() failing.

Can someone with an NTP issue post the result of these commands? Run these over SSH while the log is getting filled with the "ntp not syn" messages.

nvram get link_internet
cat /etc/resolv.conf
nslookup www.google.com
ps w | grep dnsmasq

 

[john9527]

One of the changes in GPL 7838 is ntp.c checks for link_internet being 2 instead of 1.

From what I can see, link_internet will be set to 2 if the router is able to succesfully resolve some specific hosts (such as www.google.com) in do_dns_detect(), or 1 if it fails. I suspect part of the problem is do_dns_check() failing.

Exactly what I saw when I suggested the check commands to try and break it free. And the 7838 merge occurred after 378.55

I could only find two places where do_dns_detect was called, one in wan.c in wan_up (added with 7838) and once in wanduck as part of a multiple condition check (not touched since 2012). One possibility is that the latter case is somehow not being executed and the original wan_up check fails due to some timing condition.

I did a test build adding a call to do_dns_detect as part of ntp.c as a brute force method of making sure do_dns_detect was actually being called.

 

[R1-Limited]

Cool....this confirms the 'what'....for some reason the check that the dns services are up and running is failing.
Now to figure out the 'why'.....

If you would like to continue to help debug, can you reboot (it will wipe out the changes you made) then make the syslog available? You can PM me with a location for the syslog if you prefer.

Had to reboot it all anyway RT-ac66u had to be rebooted again due to its media brdge not connecting to the 68

Results on the 68 is after reboot

Jul 31 17:02:24 hour monitor: ntp is not syn
Jul 31 17:02:36 hour monitor: daemon is starting
Jul 31 17:02:36 hour monitor: ntp is not syn

 

[R1-Limited]

One of the changes in GPL 7838 is ntp.c checks for link_internet being 2 instead of 1.

From what I can see, link_internet will be set to 2 if the router is able to succesfully resolve some specific hosts (such as www.google.com) in do_dns_detect(), or 1 if it fails. I suspect part of the problem is do_dns_check() failing.

Can someone with an NTP issue post the result of these commands? Run these over SSH while the log is getting filled with the "ntp not syn" messages.

nvram get link_internet
cat /etc/resolv.conf
nslookup www.google.com
ps w | grep dnsmasq

R1-Limited@RT-AC68U-C520:/tmp/home/root# nvram get link_internet
1

R1-Limited@RT-AC68U-C520:/tmp/home/root# cat /etc/resolv.conf
nameserver 127.0.0.1

R1-Limited@RT-AC68U-C520:/tmp/home/root# nslookup www.google.com
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name: www.google.com
Address 1: 2607:f8b0:400a:803::1014 sea09s16-in-x14.1e100.net
Address 2: 216.58.216.164 sea15s02-in-f164.1e100.net

R1-Limited@RT-AC68U-C520:/tmp/home/root# ps w |grep dnsmasq
429 nobody 1076 S dnsmasq --log-async
1541 R1-Limit 1376 S grep dnsmasq

 

[XIII]

Can someone with an NTP issue post the result of these commands? Run these over SSH while the log is getting filled with the "ntp not syn" messages.

On my RT-AC66U:

ASUSWRT-Merlin RT-AC66U_3.0.0.4 Sun Oct 25 18:29:21 UTC 2015
admin@ac66u:/tmp/home/root# nvram get link_internet
0
admin@ac66u:/tmp/home/root# cat /etc/resolv.conf
nameserver 127.0.0.1
admin@ac66u:/tmp/home/root# nslookup www.google.com
Server:  127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

nslookup: can't resolve 'www.google.com'
admin@ac66u:/tmp/home/root# ps w | grep dnsmasq
  467 nobody  1044 S  dnsmasq --log-async
  629 admin  1416 S  grep dnsmasq

So I don't get 1 or 2, but 0...

After manually correcting the date and removing and re-inserting the DNS servers on the WAN page (a suggested workaround):

admin@ac66u:/tmp/home/root# nvram get link_internet
2
admin@ac66u:/tmp/home/root# cat /etc/resolv.conf
nameserver 127.0.0.1
admin@ac66u:/tmp/home/root# nslookup www.google.com
Server:  127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:  www.google.com
Address 1: 2404:6800:4001:805::1013 kul06s08-in-x13.1e100.net
Address 2: 173.194.120.147 kul06s08-in-f19.1e100.net
Address 3: 173.194.120.148 kul06s08-in-f20.1e100.net
Address 4: 173.194.120.144 kul06s08-in-f16.1e100.net
Address 5: 173.194.120.145 kul06s08-in-f17.1e100.net
Address 6: 173.194.120.146 kul06s08-in-f18.1e100.net
admin@ac66u:/tmp/home/root# ps w | grep dnsmasq
1285 nobody  1116 S  dnsmasq --log-async
2073 admin  1416 S  grep dnsmasq

 

[RMerlin]

On my RT-AC66U:

Are you sure your WAN had successfully connected? link_internet being 0 and inability to resolve any DNS hostname would indicate there was no WAN connectivity at all.

 

[RMerlin]

R1-Limited@RT-AC68U-C520:/tmp/home/root# nvram get link_internet
1

R1-Limited@RT-AC68U-C520:/tmp/home/root# cat /etc/resolv.conf
nameserver 127.0.0.1

R1-Limited@RT-AC68U-C520:/tmp/home/root# nslookup www.google.com
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name: www.google.com
Address 1: 2607:f8b0:400a:803::1014 sea09s16-in-x14.1e100.net
Address 2: 216.58.216.164 sea15s02-in-f164.1e100.net

R1-Limited@RT-AC68U-C520:/tmp/home/root# ps w |grep dnsmasq
429 nobody 1076 S dnsmasq --log-async
1541 R1-Limit 1376 S grep dnsmasq

In your case, WAN was working properly, DNS resolution as well, but either the DNS test was done too early by the router (leaving you at state level 1), or the state check was never run by the firmware.

What type of WAN connection do you have? Any particular customization?

 

[CiscoX]

No problem with my AC68U (378.56)

admin@RT-AC68U:/tmp/home/root# nvram get link_internet
2
admin@RT-AC68U:/tmp/home/root# cat /etc/resolv.conf
nameserver 127.0.0.1

admin@RT-AC68U:/tmp/home/root# nslookup www.google.com
Server:  127.0.0.1
Address 1: 127.0.0.1 localhost.localdomain

Name:  www.google.com
Address 1: 2a00:1450:4005:801::1013 ham02s14-in-x13.1e100.net
Address 2: 80.239.174.120 80-239-174-120.customer.teliacarrier.com
Address 3: 80.239.174.119 80-239-174-119.customer.teliacarrier.com
Address 4: 80.239.174.118 80-239-174-118.customer.teliacarrier.com
Address 5: 80.239.174.117 80-239-174-117.customer.teliacarrier.com
Address 6: 80.239.174.123 80-239-174-123.customer.teliacarrier.com
Address 7: 80.239.174.122 80-239-174-122.customer.teliacarrier.com
Address 8: 80.239.174.121 80-239-174-121.customer.teliacarrier.com
Address 9: 80.239.174.116 80-239-174-116.customer.teliacarrier.com

admin@RT-AC68U:/tmp/home/root# ps w | grep dnsmasq
  415 nobody  1108 S  dnsmasq --log-async
19209 admin 1376 S  grep dnsmasq