Difficulties adding IPv6 server with chronyd to the pool


#1

This weekend I replaced my ten year old Xeon based Stratum 1 server with a Stratum 1 server based on the Raspberry Pi. I am very happy with the power usage going back from 89 Watt to just a few Watt :smile: The reference clock didn’t change: it is still the original Garmin 18LVC GPS. I used chronyd instead of ntpd because it was pre-installed in the Linux image I used. The image is the Centos 7 ARM image BTW, not the more common Raspbian image because all my Linux servers are Centos based and I like to use the same tools and configuration on all servers independent on the underlying hardware.

On IPv4 there is just a small dent in the graph as you can see at https://www.ntppool.org/scores/80.127.147.170

As the new server supports IPv6, I also wanted to add this address to the pool. When adding the server domain name ntp4.ipv6.linocomm.net to the pool, the system however responds with the message “Could not check NTP status”.

I can access the NTP server over IPv6 from my other servers in the field, so basic connectivity doesn’t seem to be a problem. But so many things changed with the move from the old to the new server that it is somewhat difficult to track down the issue.

Any hints where I should start to debug this issue?


#2

Have you tried adding the server to the beta site and see if it gets recognized there?

https://web.beta.grundclock.com/en/

I did a dig and saw the AAAA record, and even used a 3rd party site to query your ntp server so it is definitely accessible…

I’m sure Ask will chime in today, he usually responds pretty quickly on this forum…


#3

Thanks for testing. I added the server to the beta site and it responded with the same error message.


#4

I tested this with ntp2.tdc.fi. It’s a dual-stacked NTP server but not in the pool (I had no intention to add it, of course), and looks like IPv4 testing works but IPv6 gives that “Could not check NTP status” message. I’d say @ask will need to check this.


#5

Whoops – the upgrades this weekend moved the service that’s doing the checking. While moving it I did a new compile with upgraded dependencies, it looks like the IPv6 check broke. I’ll fix it tonight.

The underlying service is https://trace2.ntppool.org/ntp/ with the IP address appended.


#6

Thanks for the quick response.

Good to hear that the problem is probably identified. I’ll try again tomorrow morning.


#7

Just light up ipv6 on my network and ran into the same “Could not check NTP status” problem trying to add an ipv6 address.


#8

It should be fixed now; thank you for the report (and your patience)!

I’d updated some of the dependencies for the code that does this check and I needed to remove an earlier work around for having IPv6 work.


#9

Thanks for looking into this issue. IPv6 addresses are now recognized, but I still get an error message.

The URL https://trace2.ntppool.org/ntp/2001:984:f819:1::123 generates a response with a syscall connect error:

{"Op":"dial","Net":"udp","Source":null,"Addr":{"IP":"2001:984:f819:1::123","Port":123,"Zone":""},"Err":{"Syscall":"connect","Err":101}}

The IPv4 track URL for the same server https://trace2.ntppool.org/ntp/80.127.147.170 generates a normal resonse:

{"Time":"2018-08-04T04:36:58.17702258Z","ClockOffset":-6554427,"RTT":176390274,"Precision":1907,"Stratum":1,"ReferenceID":1347441408,"ReferenceTime":"2018-08-04T04:36:40.007519533Z","RootDelay":15258,"RootDispersion":30517,"RootDistance":88233283,"Leap":0,"MinError":0,"KissCode":"","Poll":1000000000}

Both addresses are working with ntpdate when checked from another server in the field:

[root@iris log]# ntpdate -q ntp4.linocomm.net
server 2001:984:f819:1::123, stratum 1, offset 0.000393, delay 0.06557
server 80.127.147.170, stratum 1, offset 0.001731, delay 0.06194
 4 Aug 06:33:51 ntpdate[14448]: adjust time server 80.127.147.170 offset 0.001731 sec

#10

Oh, geez. I only tested the fix on my laptop. The particular server I moved this daemon to had a bungled network configuration from a while ago when we had trouble with a new firewall and were testing if it was an MTU problem (it wasn’t, but this particular system was left with a smaller MTU).

I’ve added monitoring for the trace.ntppool.org daemon to check that it can test v4 and v6 IPs.


#11

Thanks, adding IPv6 servers is working now :+1: