no valid ntpd peers

[Maximilian Pichler]

Hi,

For some reason my ntpd doesn't get any replies from the time servers.
They can however be pinged, so I'm unsure what causes this. Any ideas?

Thanks!

Max


$ doas ntpctl -s all
0/4 peers valid, constraint offset 107s, clock unsynced

peer
wt tl st next poll offset delay jitter
203.159.70.33 from pool pool.ntp.org
1 2 - 215s 300s ---- peer not valid ----
203.158.118.2 from pool pool.ntp.org
1 2 - 215s 300s ---- peer not valid ----
203.158.247.150 from pool pool.ntp.org
1 2 - 215s 300s ---- peer not valid ----
124.109.2.169 from pool pool.ntp.org
1 2 - 215s 300s ---- peer not valid ----

$ ping 203.159.70.33
PING 203.159.70.33 (203.159.70.33): 56 data bytes
64 bytes from 203.159.70.33: icmp_seq=0 ttl=254 time=34.143 ms
64 bytes from 203.159.70.33: icmp_seq=1 ttl=254 time=34.348 ms
^C

$ doas ntpd -d -s
/var/db/ntpd.drift is empty
ntp engine ready
constraint request to 74.125.130.103
constraint request to 74.125.130.99
constraint request to 74.125.130.147
constraint request to 74.125.130.105
constraint request to 74.125.130.106
constraint request to 74.125.130.104
constraint reply from 74.125.130.147: offset 107.627988
constraint reply from 74.125.130.104: offset 107.625112
constraint reply from 74.125.130.99: offset 107.617672
constraint reply from 74.125.130.105: offset 107.616788
constraint reply from 74.125.130.103: offset 107.613464
constraint reply from 74.125.130.106: offset 107.609782
no reply received in time, skipping initial time setting
no reply from 203.159.70.33 received in time, next query 300s
no reply from 203.158.118.2 received in time, next query 300s
no reply from 203.158.247.150 received in time, next query 300s
no reply from 124.109.2.169 received in time, next query 300s

[Stuart Henderson]

Post by Maximilian Pichler
Hi,
For some reason my ntpd doesn't get any replies from the time servers.
They can however be pinged, so I'm unsure what causes this. Any ideas?

Firewall rules?

How does "rdate -nvp pool.ntp.org" look?

[Maximilian Pichler]

I should probably mention that this is OpenBSD 6.2 running under
VirtualBox on MacOS.

Post by Stuart Henderson
How does "rdate -nvp pool.ntp.org" look?

$ doas rdate -nvp pool.ntp.org
rdate: Unable to receive NTP packet from server: No route to host
rdate: Unable to receive NTP packet from server: No route to host
rdate: Unable to receive NTP packet from server: No route to host
rdate: Unable to receive NTP packet from server: No route to host
rdate: Unable to get a reasonable time estimate

On the other hand (suggested by Rudy Baker in a private message):

$ nc -vu pool.ntp.org 123
Connection to pool.ntp.org 123 port [udp/ntp] succeeded!

$ traceroute -c -p 123 pool.ntp.org
traceroute: Warning: pool.ntp.org has multiple addresses; using 203.159.70.33
traceroute to pool.ntp.org (203.159.70.33), 64 hops max, 40 byte packets
1 10.0.2.2 (10.0.2.2) 0.867 ms 0.349 ms 0.246 ms
2 * * *
3 192.168.11.1 (192.168.11.1) 2.514 ms 2.137 ms 1.786 ms
4 125.213.235.25 (125.213.235.25) 2.848 ms 2.51 ms 2.617 ms
5 125.213.235.17 (125.213.235.17) 5.88 ms 3.059 ms 3.211 ms
6 * * *
7 * * *
8 * * *
9 * 125.213.235.17 (125.213.235.17) 3.367 ms !X *

Disabling pf (as well as the firewall on the host MacOS) gives
identical results.

Also, it looks like no packets are coming back (suggested by David
Dahlberg in a private message):
$ doas tcpdump -envps1500 -i em0 port ntp or icmp
tcpdump: listening on em0, link-type EN10MB
06:16:31.765946 08:00:27:34:76:da 52:54:00:12:35:02 0800 90:
10.0.2.15.47084 > 203.158.247.150.123: [bad udp cksum cf8d! -> 5deb]
v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
(unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt
-34468692.156416639 [tos 0x10] (ttl 64, id 34769, len 76)
06:16:31.766020 08:00:27:34:76:da 52:54:00:12:35:02 0800 90:
10.0.2.15.35704 > 203.158.118.2.123: [bad udp cksum 4df9! -> 780a] v4
client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
(unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt
-95552486.879830002 [tos 0x10] (ttl 64, id 47214, len 76)
06:16:31.766340 08:00:27:34:76:da 52:54:00:12:35:02 0800 90:
10.0.2.15.31315 > 103.22.182.121.123: [bad udp cksum 29e8! -> dad3] v4
client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
(unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt
+1659942531.907521903 [tos 0x10] (ttl 64, id 53951, len 76)
06:16:31.766494 08:00:27:34:76:da 52:54:00:12:35:02 0800 90:
10.0.2.15.11278 > 203.159.70.33.123: [bad udp cksum 1e19! -> 6dc7] v4
client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
(unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt
+94128219.587299346 [tos 0x10] (ttl 64, id 30931, len 76)
06:16:31.768890 52:54:00:12:35:02 08:00:27:34:76:da 0800 90:
125.213.235.17 > 10.0.2.15: icmp: host 203.158.247.150 unreachable -
admin prohibited filter [icmp cksum ok] [tos 0xd0] (ttl 63, id 48216,
len 76)

What is "admin prohibited filter"?

Thanks for all the suggestions!

[Maximilian Pichler]

I had similar problems once under VirtualBox, other OS. try switching from NAT to BRIDGED
mode and give it a try.

Thanks, but no luck on my end. Any insight into why this should have helped?

[Stuart Henderson]

Post by Maximilian Pichler
$ doas rdate -nvp pool.ntp.org
rdate: Unable to receive NTP packet from server: No route to host

This usually indicates either not having a route, or a firewall rule
on the OpenBSD system blocking it.

Post by Maximilian Pichler
$ nc -vu pool.ntp.org 123
Connection to pool.ntp.org 123 port [udp/ntp] succeeded!

It's UDP - this indicates nothing. You haven't sent anything at this point.

Post by Maximilian Pichler
$ traceroute -c -p 123 pool.ntp.org
traceroute: Warning: pool.ntp.org has multiple addresses; using 203.159.70.33
traceroute to pool.ntp.org (203.159.70.33), 64 hops max, 40 byte packets
1 10.0.2.2 (10.0.2.2) 0.867 ms 0.349 ms 0.246 ms
2 * * *
3 192.168.11.1 (192.168.11.1) 2.514 ms 2.137 ms 1.786 ms
4 125.213.235.25 (125.213.235.25) 2.848 ms 2.51 ms 2.617 ms
5 125.213.235.17 (125.213.235.17) 5.88 ms 3.059 ms 3.211 ms
6 * * *
7 * * *
8 * * *
9 * 125.213.235.17 (125.213.235.17) 3.367 ms !X *
Disabling pf (as well as the firewall on the host MacOS) gives
identical results.
Also, it looks like no packets are coming back (suggested by David
$ doas tcpdump -envps1500 -i em0 port ntp or icmp
tcpdump: listening on em0, link-type EN10MB
10.0.2.15.47084 > 203.158.247.150.123: [bad udp cksum cf8d! -> 5deb]
v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
-34468692.156416639 [tos 0x10] (ttl 64, id 34769, len 76)
10.0.2.15.35704 > 203.158.118.2.123: [bad udp cksum 4df9! -> 780a] v4
client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
-95552486.879830002 [tos 0x10] (ttl 64, id 47214, len 76)
10.0.2.15.31315 > 103.22.182.121.123: [bad udp cksum 29e8! -> dad3] v4
client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
+1659942531.907521903 [tos 0x10] (ttl 64, id 53951, len 76)
10.0.2.15.11278 > 203.159.70.33.123: [bad udp cksum 1e19! -> 6dc7] v4
client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref
+94128219.587299346 [tos 0x10] (ttl 64, id 30931, len 76)
125.213.235.17 > 10.0.2.15: icmp: host 203.158.247.150 unreachable -
admin prohibited filter [icmp cksum ok] [tos 0xd0] (ttl 63, id 48216,
len 76)
What is "admin prohibited filter"?

Some firewalls return this for blocked packets. In this case, it seems
fairly likely that it's being blocked by 125.213.235.17.

[Maximilian Pichler]

Post by Stuart Henderson

Post by Maximilian Pichler
$ doas rdate -nvp pool.ntp.org
rdate: Unable to receive NTP packet from server: No route to host

This usually indicates either not having a route, or a firewall rule
on the OpenBSD system blocking it.

Indeed, the ISP was to blame here. Mac OS couldn't get the time
either. Once I switched to my phone's internet connection everything
was fine.

Thanks

[Craig Skinner]

Hi Maximilian,

Post by Maximilian Pichler
Indeed, the ISP was to blame here. Mac OS couldn't get the time
either. Once I switched to my phone's internet connection everything
was fine.

Perhaps the ISP has an NTP/date/time server for customers to sync from?

Cheers,

[Stuart Henderson]

Post by Maximilian Pichler

Post by Stuart Henderson

Post by Maximilian Pichler
$ doas rdate -nvp pool.ntp.org
rdate: Unable to receive NTP packet from server: No route to host

This usually indicates either not having a route, or a firewall rule
on the OpenBSD system blocking it.

Indeed, the ISP was to blame here. Mac OS couldn't get the time
either.

Ouch. It would be nice if they fixed that...