Date: Wed, 28 Jul 2004 21:15:15 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Brad Knowles <brad.knowles@skynet.be> Cc: current@freebsd.org Subject: Re: Problems with ntp4.2 when names resolve to IPv6 addresses Message-ID: <200407282115.aa83026@salmon.maths.tcd.ie> In-Reply-To: Your message of "Wed, 28 Jul 2004 20:00:01 %2B0200." <p06002000bd2d9429e65e@[192.168.50.233]>
next in thread | previous in thread | raw e-mail | index | archive | help
[Ntpd uses the first answer from getaddrinfo]
> If this were true, then pool.ntp.org would be totally and
> completely useless.
Regardless of the truth of this, pool.ntp.org would still be useful.
Ntpd calls getaddrinfo for each server directive and, as IPv4 responses
are not sorted by getaddrinfo, the response will probably be
round-robbined (or whatever your recursive name server does).
> If the initial connection attempt fails or times
> out, the next IP address in sequence should be used. However, I
> don't know how the switch-over from IPv6 to IPv4 works.
I'm fairly sure that this isn't the case. See the example at the
end of this mail where ntpd initially choses an IP that won't respond
(10.231.37.83) and over an hour later hasn't sent any bothered
switching to the IP that does respond (134.226.81.3). Then I restart
ntpd, it chooses the other IP and immediately gets a response. This
was with a ntp checkout from just befor 4.2.0.
> So far as I know, we're not doing anything unusual with regards
> to resolving IP addresses or switching from one advertised address to
> the next. If you've got IP stack problems, that's an issue we may
> not be able to help with.
Indeed.
David.
19:20:gonzo 6# cat /etc/ntp.test.conf
server testname.dwmalone.net
19:20:gonzo 7# dig a testname.dwmalone.net | grep ^testname
testname.dwmalone.net. 1H IN A 134.226.81.3
testname.dwmalone.net. 1H IN A 10.231.37.83
19:21:gonzo 8# /usr/local/bin/ntpd -c /etc/ntp.test.conf -p /var/run/ntpd.test.p
id -f /var/db/ntpd.drift
19:21:gonzo 9# /usr/local/bin/ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
10.231.37.83 .INIT. 16 u - 64 0 0.000 0.000 4000.00
19:28:gonzo 10# sleep 3600
20:29:gonzo 11# /usr/local/bin/ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
21:08:gonzo 12# killall ntpd
21:08:gonzo 13# /usr/local/bin/ntpd -c /etc/ntp.test.conf -p /var/run/ntpd.test.pid -f /var/db/ntpd.drift
21:09:gonzo 14# /usr/local/bin/ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
134.226.81.3 .GPS. 1 u 5 64 1 56.088 -113.72 0.002
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407282115.aa83026>