NTP OpenWRT 18.06.04 BusyBox. Never decreases peer checks. Spams forever at min poll. BUG?

Hello all.
I have 2 identical Linksys 1200acs.

  1. LEDE 17.01.4 < NTP works fine w/ same settings
  2. OpenWRT 18.04.04

Even after 24 hours, NTP peer checks on the OpenWRT never slow down and stay at every ~30 seconds. So if 4 NTP servers listed, conntrack shows 8 connections. Same behavior with just 1 server.
My LEDE router with same NTP settings slows to almost no checks after an hour or less, like NTP is supposed to

1 second watch on firewall. Note the times in seconds.
WAN port is internal right now. Testing. So this is not a gateway.

Every 1.0s: cat /proc/net/nf_conntrack | grep dport=123                               
ipv4     2 udp      17 **58** src=192.168.128.104 dst=216.239.35.0 sport=32996 dport=123 packets=1 bytes=76 src=216.239.35.0 dst=192
.168.128.104 sport=123 dport=32996 packets=1 bytes=76 mark=0 zone=0 use=2
ipv4     2 udp      17 **25** src=192.168.128.104 dst=216.239.35.0 sport=39618 dport=123 packets=1 bytes=76 src=216.239.35.0 dst=192
.168.128.104 sport=123 dport=39618 packets=1 bytes=76 mark=0 zone=0 use=2

Never slows down and ntptime is always off

root@OpenWrt:~# ntptime -status
ntp_gettime() returns code 5 (**ERROR**)
  time e10fa747.a48ad000  Tue, Aug 27 2019  7:57:43.642, (.642743),
  maximum error 16000000 us, estimated error 16000000 us
ntp_adjtime() returns code 0 (OK)
  modes 0x10 (STATUS),
  offset -31444.000 us, frequency -500.000 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16000000 us,
  status 0x0 (),
  time constant 4, precision 1.000 us, tolerance 500 ppm,

NTP system settings were stock. All changed in GUI.
I did a pin-reset and tried again and got the same results. NTP always lags and never syncs.

To rule out the NTP severs, I used FQDN (ex: time1.google.com) and in a Debian VM, I used the same servers and it synced and slowed down after about 20 minutes. So it's just the OpenWRT router.

ntpq/ntpc times out on localhost. I read that's common and has to do with binding to IPv6 by default (which don't use)

Any help or advice would be welcome. Thank you.

ntptime is not installed by default, neither is ntpdc or ntpq. Are you sure you didn't install ntp-utils or ntpdate?

Additionally ntpd is not installed by default. Did you install/enable it; and also disable the built-in Busybox ntp?

2 Likes

Is this NTP, as in the reference implementation installed as a package, or the busybox-based implementation?

Also, what router?

A 500 ppm offset is rather surprising with something like a 20 ppm accuracy required for 802.11 RF generation.

2 Likes

Hello.
I did install ntp-utils from opkg to use ntptime. Nothing else ntp related
I'm using busybox ntp (sym link). Didn't install ntp

Hello
Router: Linksys 1200AC v2. I own 2. The other is my gateway.
This is my 5th update/upgrade using LEDE/OpenWRT. DDWrt before this.

/proc/cpuinfo
model name      : ARMv7 Processor rev 1 (v7l) X 2
Hardware        : Marvell Armada 380/385 (Device Tree)

Using just stock settings for busybox ntp

root@OpenWrt:/proc/2704/net# ls -alths /usr/sbin/ntpd
     0 lrwxrwxrwx    1 root     root          17 Jun 27 12:18 /usr/sbin/ntpd -> ../../bin/busybox
root@OpenWrt:/proc/2704/net# uci show | grep ntp
system.ntp=timeserver
system.ntp.enabled='1'
system.ntp.enable_server='0'
system.ntp.server='0.openwrt.pool.ntp.org' '1.openwrt.pool.ntp.org' '2.openwrt.pool.ntp.org' '3.openwrt.pool.ntp.org'
ucitrack.@ntpclient[0]=ntpclient
ucitrack.@ntpclient[0].init='ntpclient'
root@OpenWrt:/proc/2704/net# ps w | grep ntp
 2260 root      1060 S<   /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p 0.openwrt.pool.ntp.org -p 1.openwrt.pool.ntp.org -p 2.o

I reset the router again. Totally stock now. Didn't upgrade or install anything. Just gave root as p/w.
It's showing the same behavior.
So it's certainly not settings

root@OpenWrt:/proc/2704/net# opkg list-installed | grep ntp
root@OpenWrt:/proc/2704/net#     < BLANK

Stock NTP config. Client, not server. Not changed anything

root@OpenWrt:/proc/2704/net# uci show | grep ntp
system.ntp=timeserver
system.ntp.enabled='1'
system.ntp.enable_server='0'
system.ntp.server='0.openwrt.pool.ntp.org' '1.openwrt.pool.ntp.org' '2.openwrt.pool.ntp.org' '3.openwrt.pool.ntp.org'
ucitrack.@ntpclient[0]=ntpclient
ucitrack.@ntpclient[0].init='ntpclient'

Same behavior. Spamming peer checks every 30 seconds. I reset it about 2 hours ago. No utils to check ntptime

root@OpenWrt:/proc/2704/net# cat /proc/net/nf_conntrack | grep dport=123
ipv4     2 udp      17 20 src=192.168.128.104 dst=23.31.21.164 sport=55488 dport=123 packets=1 bytes=76 src=23.31.21.164 dst=192.168.128.104 sport=123 dport=55488 packets=1 bytes=76 mark=0 zone=0 use=2
ipv4     2 udp      17 46 src=192.168.128.104 dst=45.43.30.59 sport=50393 dport=123 packets=1 bytes=76 src=45.43.30.59 dst=192.168.128.104 sport=123 dport=50393 packets=1 bytes=76 mark=0 zone=0 use=2
ipv4     2 udp      17 46 src=192.168.128.104 dst=129.250.35.251 sport=47597 dport=123 packets=1 bytes=76 src=129.250.35.251 dst=192.168.128.104 sport=123 dport=47597 packets=1 bytes=76 mark=0 zone=0 use=2
ipv4     2 udp      17 53 src=192.168.128.104 dst=23.31.21.164 sport=53407 dport=123 packets=1 bytes=76 src=23.31.21.164 dst=192.168.128.104 sport=123 dport=53407 packets=1 bytes=76 mark=0 zone=0 use=2
ipv4     2 udp      17 30 src=192.168.128.104 dst=66.228.58.20 sport=45083 dport=123 packets=1 bytes=76 src=66.228.58.20 dst=192.168.128.104 sport=123 dport=45083 packets=1 bytes=76 mark=0 zone=0 use=2
ipv4     2 udp      17 14 src=192.168.128.104 dst=129.250.35.251 sport=41487 dport=123 packets=1 bytes=76 src=129.250.35.251 dst=192.168.128.104 sport=123 dport=41487 packets=1 bytes=76 mark=0 zone=0 use=2
ipv4     2 udp      17 14 src=192.168.128.104 dst=45.43.30.59 sport=50711 dport=123 packets=1 bytes=76 src=45.43.30.59 dst=192.168.128.104 sport=123 dport=50711 packets=1 bytes=76 mark=0 zone=0 use=2

I'm very confused now.

Please feel free to use one post to reply to multiple people, we can all see the replies.

  • Can you try enabling the server?
  • If that doesn't work, can you try using ntpd?

I'm seeing NTP query/response with the configured servers quite often on a build from master from this July. It seems to be running at 64 s with "busybox" NTP.

2 Likes

Plot-twist:
Same router--I installed luci-app-advanced-reboot and rebooted back to the previous partition (linksys 1200 has 2) with LEDE 17.01.4 on it.
NTP works fine...
Steps down poll time in 15 minutes, like it's supposed to

root@Testrouter:~# cat /proc/net/nf_conntrack | grep dport=123
ipv4     2 udp      17 0 src=192.168.128.104 dst=184.105.182.16 sport=50456 dport=123 packets=1 bytes=76 src=184.105.182.16 dst=192.168.128.104 sport=123 dport=50456 packets=1 bytes=76 mark=0 zone=0 use=2

EDIT to show ntp config

root@Testrouter:~# uci show | grep ntp
system.ntp=timeserver
system.ntp.enabled='1'
system.ntp.server='0.lede.pool.ntp.org' '1.lede.pool.ntp.org' '2.lede.pool.ntp.org' '3.lede.pool.ntp.org'
ucitrack.@ntpclient[0]=ntpclient
ucitrack.@ntpclient[0].init='ntpclient'

So something is up with 18.06's NTP here.

1 Like

Hello Jeff.
The image I used is very recent. Just downloaded it last week

http://downloads.openwrt.org/releases/18.06.4/targets/mvebu/cortexa9/openwrt-18.06.4-mvebu-cortexa9-linksys-wrt1200ac-squashfs-sysupgrade.bin

NTP is supposed to modify it's polling intervals as it gets closer to sync. Rolling back to LEDE 17x, it's working fine.
So if you're seeing peer checks to all peers @ 64 seconds (default lowest) then it's probably broken for you too.

EDIT:
lleachii
I did test ntpd. The server worked (and did sync and step down polling) but clients couldn't connect. Other posts I found showed other people had issues with it too.
I gave up on that to focus on busybox ntp to maybe work

I'm back to fresh images now. openwrt 18.4.6 stock and lede 17.1.4 with no special ntp mods/configs
openwrt wrt doesn't work, lede does.

I installed the "snapshot" NTP package on one of my active APs and I'm seeing low reachability, so I've got to look into that in more detail. It isn't as if one remote isn't responding, but it looks like all of them fail for a given query cycle. Low reachability probably means that the NTP algorithms don't back off.

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+shed.galexander 180.165.246.68   3 u   39   64  137   10.495    0.135   2.580
+clock.team-cymr 204.9.54.119     2 u   35   64  137   58.572   -0.706   3.099
-69.10.161.7     195.205.216.85   3 u   39   64  137   23.836   -1.864   2.044
*io.crash-overri 129.7.1.66       2 u   44   64  137   50.188    0.798   1.803
1 Like

Can anyone confirm it's working for them on 18.06.04?
If it's broke for everyone, it's a bug and I'll move on and wait for the next image update where this is hopefully fixed.