inherit rootdelay from the delay from the last client update from the peer
that we picked last time to adjust the local clock.
in some cases we use the average offset between two peers' client updates,
then use the average delay between the two as well.
code path for NTP4 remains unchanged, we already set refid correctly there.
NTP3 and older uses an IPv4 address as refid.
use the IP of the server we last synced to if it was a IPv4 one.
sometimes we use the average offset between two, in that case just pick
one for the IP.
this scheme naturally fails when we query IPv6 servers and have to reply
to IPv4 NTP3 (or even older NTP versions) clients - refid stays at 0 then.
this is a protocol limitation, nothing we can do about it.
might have become invalid (because the peer showed up, dns request sent to
parent, peer vanishes, and then the reply comes back), so do not fatal() in
that case but just log_warnx(). provoked by brad
connect it, instead leave it at -1.
in client_query, set up and connect the socket if it is -1.
and, the real reason for this change: handle connect failures gracefully
ok otto
offset to correct the local clock, but use the median.
given a reasonable sized set of servers this makes us nearly immune against
outliers or flasetickers, without the need for a horribly complicated outliers
detection which does not yield to better results anyway.
test & ok otto
once at startup. ntpd delays daemonizing until it has done the intial
time setting (or ran into the timeout) in this mode to make sure stuff started
later in rc is not subject to time jumps.
this eleminates the need to run rdate -n beforehands.
with some input from & ok ryan and bob, march music from mickey
-kill the _pid flavors of imsg_create and imsg_compose, and just add pid as
argument to those
-use imsg_create in imsg_compose instead of duplicating code
-check for datalen overflow
asking the privileged one to do it. sends back an imsg with the
resulting addresses in a bunch of struct sockaddr_storage in the data
part.
this should fix all remaining issues with dns (non-)availability at
ntpd startup, be it due to named on localhost or something else.
tested by marco@ and Chris Paul <chris.paul@sentinare.com>