<h4 id="aux">Auxilliary Commands</h4>
<dl>
<dt><tt>broadcastclient [novolley]</tt>
- <dd>This command enables reception of broadcast server messages to any local interface (type <tt>b</tt>) 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 <tt>novolley</tt> keyword is present, the exchange is not used and the value specified in the <tt>broadcastdelay</tt> command is used or, if the <tt>broadcastdelay</tt> 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 <a href="authopt.html">Authentication Options</a> page. Note that the <tt>novolley</tt> keyword is incompatible with public-key authentication.
- <dt><tt>manycastserver <i>address</i> [...]</tt>
- <dd>This command enables reception of manycast client messages to the multicast group address(es) (type <tt>m</tt>) 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 <a href="authopt.html">Authentication Options</a> page.
+ <dd>This command enables reception of broadcast server messages to any local interface (type <tt>b</tt>) 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 <tt>novolley</tt> keyword is present, the exchange is not used and the value specified in the <tt>broadcastdelay</tt> command is used or, if the <tt>broadcastdelay</tt> 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 <a href="authopt.html">Authentication Options</a> page. Note that the <tt>novolley</tt> keyword is incompatible with public key authentication.<dt><tt>manycastserver <i>address</i> [...]</tt>
+ <dd>This command enables reception of manycast client messages to the multicast group address(es) (type <tt>m</tt>) 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 <a href="authopt.html">Authentication Options</a> page.
<dt><tt>multicastclient <i>address</i> [...]</tt>
- <dd>This command enables reception of multicast server messages to the multicast group address(es) (type <tt>m</tt>) 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 <a href="authopt.html">Authentication Options</a> page.
+ <dd>This command enables reception of multicast server messages to the multicast group address(es) (type <tt>m</tt>) 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 <a href="authopt.html">Authentication Options</a> page.
++ <dt><tt>dynamic</tt>
++ <dd>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).
</dl>
<h4 id="bug">Bugs</h4>
<p>The syntax checking is not picky; some combinations of ridiculous and even hilarious options and modes may not be detected.</p>
<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
</body>
--</html>
++</html>
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)