From: Frank Kardel Date: Sat, 15 Oct 2005 06:35:12 +0000 (+0000) Subject: Merge bk://www.ntp.org/home/bk/ntp-dev X-Git-Tag: NTP_4_2_3P2~5^2~14^2~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=2fcb3ac31190af7753e5ea145669747b4b8028f1;p=thirdparty%2Fntp.git Merge bk://www.ntp.org/home/bk/ntp-dev into pogo.udel.edu:/pogo/users/kardel/dynamic-if/ntp-dev bk: 4350a320D6LNOMlhv-mHImA71AWgew --- 2fcb3ac31190af7753e5ea145669747b4b8028f1 diff --cc html/confopt.html index 4e428d241,54f14defe..ab9f6eb59 --- a/html/confopt.html +++ b/html/confopt.html @@@ -67,10 -78,11 +67,12 @@@

Auxilliary Commands

broadcastclient [novolley] -
This command enables reception of broadcast server messages to any local interface (type b) address. Ordinarily, upon receiving a message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange with the server, after which it continues in listen-only mode. If the novolley keyword is present, the exchange is not used and the value specified in the broadcastdelay command is used or, if the broadcastdelay command is not used, the default 4.0 ms. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page. Note that the novolley keyword is incompatible with public-key authentication. -
manycastserver address [...] -
This command enables reception of manycast client messages to the multicast group address(es) (type m) specified. At least one address is required, but The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to limit the span of the reply and avoid a possibly massive implosion at the original sender. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page. +
This command enables reception of broadcast server messages to any local interface (type b) address. Ordinarily, upon receiving a message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange with the server, after which it continues in listen-only mode. If the novolley keyword is present, the exchange is not used and the value specified in the broadcastdelay command is used or, if the broadcastdelay command is not used, the default 4.0 ms. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the Authentication Options page. Note that the novolley keyword is incompatible with public key authentication.
manycastserver address [...] +
This command enables reception of manycast client messages to the multicast group address(es) (type m) specified. At least one address is required. The NTP multicast address 224.0.1.1 assigned by the IANA should NOT be used, unless specific means are taken to limit the span of the reply and avoid a possibly massive implosion at the original sender. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the Authentication Options page.
multicastclient address [...] -
This command enables reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric-key or public-key authentication as described in the Authentication Options page. +
This command enables reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the Authentication Options page. ++
dynamic ++
Allows a server/peer to be configured even if it is not reachable at configuration time. It is assumed that at some point in the future the network environment changed so that this server/peer can be reached. This option is usful to configure servers/peers on mobile systems with intermittent network access (e.g. wlan clients).

Bugs

The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected.

@@@ -78,4 -90,4 +80,4 @@@ -- ++ diff --cc ntpd/ntp_proto.c index 4d210c60e,283cbb7ff..90a8cccaa --- a/ntpd/ntp_proto.c +++ b/ntpd/ntp_proto.c @@@ -2931,9 -2960,8 +2974,9 @@@ peer_unfit ULOGTOD(sys_poll)) rval |= TEST11; /* distance exceeded */ - if (peer->stratum > 1 && (peer->refid == - if (peer->stratum > 1 && (!peer->dstadr || peer->dstadr->addr_refid == - peer->refid)) ++ if (peer->stratum > 1 && (!peer->dstadr || peer->refid == + peer->dstadr->addr_refid || (peer->refid == sys_refid && + peer->refid != htonl(LOOPBACKADR)))) rval |= TEST12; /* synch loop */ if (!peer->reach || peer->flags & FLAG_NOSELECT)