[Solved] Clock keeps going horribly out of sync

I've been having a weird issue for a while with my Fritzbox 4020.

Right now it's 30/07/2022 19:53, but the router thinks it's 21/4/2022 04:03 instead.
It's not the first time I find the time and date completely messed up, I usually run the manual sync and it works (both with the browser sync and NTP manual sync).
However, I don't know how after how long it happens since the router works fine and I rarely open the page, it will go completely bonkers, and by what is frankly a ridiculous amount that surely can't be attributed to clock inaccuracies only.
Again, apart from that and a couple of minor issues (the reboot button doesn't work and netdata needs to be rebooted once in a while) the router works just fine so I never worried about it too much, but now I wanted to try and understand why this happens.

In the System > Time Syncronization tab "Enable NTP client" is checked.

If I run "uci show system" I get:

root@OpenWrt:~# uci show system
system.@system[0]=system
system.@system[0].hostname='OpenWrt'
system.@system[0].ttylogin='0'
system.@system[0].log_size='64'
system.@system[0].urandom_seed='0'
system.@system[0].log_proto='udp'
system.@system[0].conloglevel='8'
system.@system[0].cronloglevel='5'
system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3'
system.@system[0].zonename='Europe/Rome'
system.ntp=timeserver
system.ntp.server='0.it.pool.ntp.org' '1.it.pool.ntp.org' '2.it.pool.ntp.org'
system.led_wan=led
system.led_wan.name='WAN'
system.led_wan.sysfs='fritz4020:green:wan'
system.led_wan.trigger='netdev'
system.led_wan.mode='link tx rx'
system.led_wan.dev='eth1'
system.led_lan=led
system.led_lan.name='LAN'
system.led_lan.sysfs='fritz4020:green:lan'
system.led_lan.trigger='switch0'
system.led_lan.port_mask='0x1E'
root@OpenWrt:~#

Is something wrong with my configuration?

IMPORTANT EDIT: I've noticed something I should have tried before, the router appears to go completely out of sync right after a reboot.
What could be the cause of that?

Are you running a VPN as default route?

Nope, and I don' think there is any problem while communicating with the NTP servers since it works without issues when I try using the NTP manual sync from the GUI.

Find your WAN port designation on the Overview page and adjust as necessary and add these command to the rc.local

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
ntpd -d -n -q -N -I eth1 -p 162.159.200.123 -p 203.114.74.17
exit 0

Cobbled together a pic to show where the change goes.

Add the command Save... Reboot.. Log back in and look at your System Log for the adjustments to be made..
It won't be big duration because you touched a file config and the router will base it timestamp on the rc.local file being saved by the timestamp on the router.

This is basically like running the manual command at the startup right? Cuz that's what I thought I could do to fix it, but I was wondering what might be the cause of the problem!

Being out of sync on a reboot is common on routers without a Real Time Clock. The router therefore will boot the timestamp of the latest modified timestamp on the system files.

Seen a couple post and one was related to packages that modify the dnsmasq as the default handler of DNS. The below is just one of them. So the question is do you have any add-on doing DNS?

DNS:

As i dont require the router to be filtered. i explicitly set the router to have its own upstream that uses regular UDP dns which also avoids the NTP issue. (router doesnt have correct time and cannot update via secure DNS as the time is wrong)

YES

1 Like

Ok, 162.159.200.123 203.114.74.17 are IPs for NTP servers right? Could I just try and paste the command you gave me but with the name of my servers instead? As I said, I'm pretty sure it's not a DNS problem since manual sync works.

ETC...

I'd use the IP address instead of the name.
PING 0.it.pool.ntp.org (37.247.53.178): 56 data bytes

/etc/config/dhcp
config dnsmasq
...
	list server '/3.XX.pool.ntp.org/8.8.4.4'
	list server '/2.XX.pool.ntp.org/8.8.4.4'
	list server '/1.XX.pool.ntp.org/149.112.112.10'
	list server '/0.XX.pool.ntp.org/9.9.9.10'
...

I've tried via ssh and "ntpd -q -p 0.it.pool.ntp.org" works if done manually, however it doesn't appear to be working when used at the startup.
It doesn't work if I use 37.247.53.178 at the startup either, but if I use it via ssh it works with the IP.

I've tried with (i know it's not complete and that I probably shouldn't mix IPs and hostnames, but that's probably not the problem)
ntpd -d -n -q -N -I eth1 -p 37.247.53.178 -p 1.it.pool.ntp.org
Which works if used manually but not on the startup.
:confused:

Is this your ISP wan? Mine are below: Be sure your rc.local command has the correct device name.

/etc/config/network


config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'

config device
	option name 'eth1'
	option macaddr 'ec_d_88c7:7b:8'
	option ipv6 '0'

config interface 'wan'
option ifname 'eth1' 
option proto 'pppoe'
option password '************'
option ipv6 'auto'
option username '**************'

Took me a bit to open it with vi because I'm not so used to Unix stuff :smiley:

That said, this is what I got. When I tried the command you gave me via ssh it worked without any problem, so I don't think there was any issue with it.

So what does the system log say when it rolls over the rc.local init. when rebooting?

Yeah.. vi's great for people who know, and type..
The Overview page on LuCi has that info. Hard to spot on my cobbled image as on image is overlaid onto the larger.

How do I read that?

Two ways:

  • One is to log into your router's Web LuCi, and look at System Log.
  • The other is ssh into the router and type the command logread

I know how to read the System Log but I don't know what I'm looking for, if I try searching for rc.local or "ntp" related stuff I can't find anything.

Looking for this:


Sat Jul 30 17:39:41 2022 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 203.114.74.17
Sat Jul 30 17:39:41 2022 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 162.159.200.123
Sat Jul 30 17:39:41 2022 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 162.159.200.123: offset:+0.004997 delay:0.048076 status:0x24 strat:3 refid:0x0a1d0871 rootdelay:0.022965 reach:0x01
Sat Jul 30 17:39:43 2022 daemon.notice procd: /etc/rc.d/S95done: ntpd: sending query to 162.159.200.123
Sat Jul 30 17:39:43 2022 daemon.notice procd: /etc/rc.d/S95done: ntpd: reply from 162.159.200.123: offset:+0.003212 delay:0.062613 status:0x24 strat:3 refid:0x0a1d0871 rootdelay:0.023377 reach:0x03

Nope, nothing like that... however I might have spotted the issue.
This is what my startup looks like:

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

# Comando iperf3
logger "Lancio iperf3"
iperf3 -s
logger "iperf3 lanciato"

# Sync orologio
logger "Primo test sync orologio"
ntpd -d -n -q -N -I eth1 -p 37.247.53.178 -p 1.it.pool.ntp.org
sleep 120
logger "Secondo test sync orologio dopo sleep"
ntpd -d -n -q -N -I eth1 -p 37.247.53.178 -p 1.it.pool.ntp.org

# Comandi per aggiungere indirizzi e MAC per WoL
ip neigh add 192.168.1.200 lladdr 00:00:c0:2b:6e:11 nud permanent dev br-lan
ip neigh add 192.168.1.100 lladdr 70:85:c2:69:3b:e5 nud permanent dev br-lan
sleep 30
ip neigh replace 192.168.1.200 lladdr 00:00:c0:2b:6e:11 nud permanent dev br-lan
ip neigh replace 192.168.1.100 lladdr 70:85:c2:69:3b:e5 nud permanent dev br-lan
exit 0

I added some "logger" entries to check if it actually ran all the commands, and I found out that the sequence stops right after iperf3 is launched (the iperf3 server works, but I never see "iperf3 lanciato") in the log.
Sooo... every command I've tried so far probably would have worked just fine since they worked anually, they simply weren't issues apparently! :man_facepalming:
I'll try figuring out why it happens, I have a suspicion that it might be due to the iperf3 command syntax, I'll run a couple of tests now!

I've got a WHOLE WEEK of posts with that written for all to see for eternity.

Found the issue, as I suspected it was caused by iperf3.

I had to use "iperf3 -s -D" to enable daemon mode, otherwise it apparently behaves like in Windows, where if you simply launch it as "iperf3 -s" it "takes control" of the cmd and doesn't let you issue more commands with the prompt.
I guess the same happens with the startup console, once iperf3 took control it wouldn't let the other commands run.

ntp sync works flawlessly now with your command, and I guess it also does with the simpler one I tried issuing manually :partying_face:

1 Like