cturra/docker-ntp

Migration to chrony broke IPv4 connectivity

smirnov-tk opened this issue · 4 comments

smirnov-tk commented

My NTP server address is ntp.smirnov.tk
It has IPv4 and IPv6.

Today night container was upgraded and some clients can't get reply from my NTP server.

You can see it here: https://www.ntppool.org/a/smirnov
IPv4 is dead, but IPv6 is ok.

Also this service shows IPv4 dead: https://servertest.online/ntp

But this service shows IPv4 alive: https://keetweej.vanheusden.com/query_ntp.php

UPD: I used docker tag cturra/ntp:strip-quotes and now IPv4 connectivity is OK. So, I think, it's some kind of problem in chrony update.

cturra commented

@smirnov-tk thanks for reaching out and i'm sorry to hear you're having a challenge with the update from openntpd to chrony.

i have been trying to reproduce this same issue locally and so far have not had any luck. here is some really basic testing i have done:

(locally) query ntp service over ipv6:

$> ntpdate -6 -q ::1
server ::1, stratum 4, offset -0.000011, delay 0.02585
19 Mar 09:35:16 ntpdate[6907]: adjust time server ::1 offset -0.000011 sec

(locally) query ntp service over ipv4:

$> ntpdate -4 -q 127.0.0.1
server 127.0.0.1, stratum 4, offset -0.000009, delay 0.02599
19 Mar 09:35:31 ntpdate[7021]: adjust time server 127.0.0.1 offset -0.000009 sec

i want to spend more time on this, but figured it'd be good to offer up an alternate solution for you in the mean time. if you'd like to revert back to using the older openntpd version of this container, you can do the following:

# clone the github repo
$> git clone https://github.com/cturra/docker-ntp.git

# jump into the repo and revert to an older commit
$> cd docker-ntp
$> git reset --hard dbdfe38aea5c097b06f43957bb5e423309675c68

# build and run the container
$> ./build.sh
$> ./run.sh
smirnov-tk commented

@cturra thanks for your reply!

I mean not all IPv4 connections not working, but some of the clients can't get response or get incorrect response (as pool.ntp.org checker also do). My local clients sync successfully. Some remote clients (as online NTP checkers - also do). But some fail.

I tried to check clients list with chronyc clients and I see requests from pool.ntp.org and every other failing client and no dropped packets there. So, does that mean, that chrony is replying them? Why they might fail? How can I test it?

smirnov-tk commented

@cturra lucky me, my remote server also failing to query my home server.

Here is what I get using previous container version:

# ntpdate -q 94.29.93.171
server 94.29.93.171, stratum 2, offset 0.000045, delay 0.06451
21 Mar 18:22:38 ntpdate[5461]: adjust time server 94.29.93.171 offset 0.000045 sec

That's what I get, when trying with chronyc version:

# ntpdate -q 94.29.93.171
server 94.29.93.171, stratum 0, offset 0.000000, delay 0.00000
21 Mar 18:25:13 ntpdate[5541]: no server suitable for synchronization found

Any thoughts?

UPD: I switched from host mode to bridge mode and then everything is OK.

smirnov-tk commented

The final fix is run this container only in bridge mode. I couldn't make it work in host mode, as my local server is behind NAT and chrony can't see the real IP to listen to.
I also tried in config:

bindaddress 0.0.0.0
bindaddress ::

But this config didn't help.
I can define my external IP via bindaddress, but my external IP is dynamically assigned by my ISP.