[ntp:questions] handling falseticker

catia.lavalle at bechtle.com catia.lavalle at bechtle.com
Thu Feb 19 16:26:05 UTC 2009


you are right this is a way to influence NTP from the command line without 
changinh the ntp.conf file, but still I do not reach my aim, at least not 
the way I imagine it.

With ntpdc I can add a new peer (server) or remove it but not force to 
"change its mind" about two already existing peers (servers). You are 
right in he sense: if I want to exclude a server from the server list 
without stopping and restarting the deamon this is the way, but this is 
more drastic than what I would like to have.

I mean say at time X one of the 2 stratum 1 "goes mad" such that:

  remote        refid
*         .GPS.
x10.1.1.2         .DCF.      .LOCL.

the is not deleted is just "put on hold"/"right now ignored but 
not forever". If after a while it starts to give the correct time again it 
will be accepted again automatically. If I would by brute force remove it 
from the list (no matter if with a ntp restart or from command line) it 
will be away till when I manually ddecide that now it is again trustful 
and I manually re-add it to the server list.

What I have in mind is a sort of "one time prefer command". 


Externe Mail : Martin Burnicki <martin.burnicki at meinberg.de> 18.02.2009 

catia.lavalle at bechtle.com

questions at lists.ntp.org

Re: [ntp:questions] handling falseticker

catia.lavalle at bechtle.com wrote:
> Hello,
> what you describe is not the situation I have in mind.
> You describe a "lost sync" of one of the 2 Stratum 0. This is not a
> falseticker situation. This would lead to a "lost sync" or a "sync to
> local host" which will be transferred up down on the whole  NTP tree,
> recognized by the clients and this NTP path will be ignored. Everything 
> clean everything is fine. And everything could be easily monitored (a 
> sync is an error message!)
> What I describe is a falsetiker as for example: suppose that the DCF
> signal gives you the correct time, the GPS signal has a failure (it 
> apart a bit but not soo much that NTP refuses to stay sync)  and DOES 
> you a time BUT a wrong one. This is less easy to monitor since there no
> error!
> Both Stratum 1 will keep being sync with the respective Stratum 0 
> they DO receive a time and this time is not soooo wrong to stop syncing
> (is not a huge jump ... say is a slow drift).
> The Stratum 2 will receive time from the Stratum 1. Will see that both 
> syncing with a Stratum 0 i.e. in principle they are both trustable but
> their time is too far apart to assume that both are correct.
> This means NTP has to decide which one is the wrong one. In this case 
> would decide which one gives the wrong time i.e. to be rejected as 
> with a voting criterion. The problem is that a voting criterion works 
> with up to 3 (well 4) servers. With 2 servers it does not work (no
> majority reach!). So NTP is forced to take anyway a decision but without
> enough elements at hand to know which is the right decision to take i.e.
> the decision it will take is not necessarily the correct one.
> Here my question.
> Say the decision taken is wrong. I realize it in some way (no matter 
> and I want to correct it. I.e. I want to force NTP to switch from:
>   remote        refid
> =======================
> *               .GPS.
> x10.1.1.2         .DCF.
>            .LOCL.
> to
>   remote        refid
> =======================
> x10.1.1.1               .GPS.
> *         .DCF.
>            .LOCL.
> from the command line without having to change the ntp.conf file.
> Is it possible?? How??

You can use the ntpdc tool to change the configuration of a running NTP 
on the fly.

However, the NTP daemon accepts commands from ntpdc only if symmetric key 
authentication is enabled.

To enable symmetric key authentication there must be a file which contains 
keys, e.g. /etc/ntp.keys with the following line

-- <snip> -----------------------
1 M mysecret
2 M myothersecret
3 M onemoresecret
-- <snip> -----------------------

The 1st column is the key ID, just a number to identify one of the keys in 

The 2nd column is an abbreviation for the algorithm. 'M' is for MD5 and is 

what you should use.

The 3rd column represents the passphrase for the key.

In order to enable symmetric key authentication for the NTP daemon the 
file /etc/ntp.conf must contain the following lines:

-- <snip> -----------------------
keys /etc/ntp.keys   # path for keys file
trustedkey 1 2 3     # define all trusted keys
requestkey 2         # key (2) to use with ntpdc
controlkey 3         # key (3) to use with ntpq 
-- <snip> -----------------------

The "trustedkey" line contains a summary of all key IDs from the ntp.keys 
which shall be trusted.

The "requestkey" specifies the key to be used with ntpdc.

The "controlkey" specifies the key to be used with ntpq, though NTP bug 
indicates this has never been implemented:

If you have changed the config file you should restart the NTP daemon. 
the values from the example above you should be able to use ntpdc to ...

... remove a selected server association:
ntpdc -c "keyid 2" -c "passwd myothersecret" -c "unconfig"

... add a selected server association:
ntpdc -c "keyid 2" -c "passwd myothersecret" -c "addserver"

If you don't add the keyid and passwd on the command line you will be 
for it.

Hope this helps.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list