[ntp:hackers] Does ntpd need to whine more ?

todd glassey todd.glassey at worldnet.att.net
Sun Oct 2 01:16:45 UTC 2005


Not necessarily NTP - but perhaps an NTP-Alarm Manager Agent thingee could -
NTP needs to do one thing and one thing only and that is manage the
distribution of time data and possibly the authentication of the end-points
of the process although event that might be better off unbundled.

As to the station's keeping parts of operating a clock, from an audit
perspective that is more of something that the system used to create the
proper evidence of operation would do...

Just my 2 cents.

Todd

----- Original Message ----- 
From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
To: <hackers at ntp.isc.org>
Sent: Saturday, October 01, 2005 1:32 AM
Subject: [ntp:hackers] Does ntpd need to whine more ?


>
> I examined the client population of my public NTP server today and one
> of the things I noticed is that people don't seem to notice when their
> time sync stops working and falls back to localclock or bogusly
> configured refclocks:
>
> IP number         port leap v m  s  p   P         offset refid
> 83.93.121.52       123 no   3 3  8 10 -18        -870219 [CHU_AUDIO#1]
> 213.150.46.130     123 no   4 3  6  9 -18       -45885.3 [LOCALCLOCK#0]
> 193.80.34.55       123 no   4 3 11  6 -17       -1200.67 [LOCALCLOCK#0]
> 80.163.104.246     123 no   4 3 11  7 -17 -861.909907751 [LOCALCLOCK#0]
> 84.252.140.74      123 no   4 3 11 10 -17 -656.351917002 [LOCALCLOCK#0]
> 195.137.236.98     123 no   4 3 11 10 -16 -552.525271231 [LOCALCLOCK#0]
> 62.168.70.34       123 no   4 3 11 10 -17 -490.447245817 [LOCALCLOCK#0]
> 213.237.12.42      123 no   4 3 11 10 -14 -417.127059488 [LOCALCLOCK#0]
> 84.252.140.75      123 no   4 3 11 10 -17 -390.175941129 [LOCALCLOCK#0]
> 194.182.59.131     123 no   4 3 11 10 -17 -352.907590295 [LOCALCLOCK#0]
> 130.225.55.45      123 no   4 3 11 10 -20 -211.406927092 [LOCALCLOCK#0]
> 80.167.36.195      123 no   4 3 11  6 -20  -76.492007285 [LOCALCLOCK#0]
> 80.197.228.145     123 no   3 3  1  6 -18  -74.212584697 [LOCL]
> 84.178.115.155     123 no   4 3 11 10 -17  -72.637406968 [LOCALCLOCK#0]
> 81.222.178.14      123 no   4 3  9 13 -18  -34.199476455 [LOCALCLOCK#0]
> 81.7.135.212       123 no   4 3 11 10 -16   -7.480777256 [LOCALCLOCK#0]
> 213.179.234.164    123 no   4 3  9  6 -20   -4.997523351 [LOCALCLOCK#0]
> 194.30.128.215     123 no   3 3  3  6 -18   -1.377271947 [CHU_AUDIO#1]
> 195.215.251.62     123 no   4 3 11 10 -16   -1.022872705 [LOCALCLOCK#0]
> 213.227.247.22     123 no   4 3 11  8 -19    0.298256985 [LOCALCLOCK#0]
> 62.79.13.226       123 no   4 3 11 10 -18   36.248626570 [LOCALCLOCK#0]
> 81.7.185.4         123 no   3 3  1  6 -18   64.376627500 [LOCL]
> 84.178.108.198     123 no   4 3 11  9 -17   73.076912553 [LOCALCLOCK#0]
> 80.208.105.200     123 no   4 3 11 10 -16  660.936837740 [LOCALCLOCK#0]
>
> I can almost guarantee that none of the two that use CHU_AUDIO meant to,
> because neither is in range of Canada as far as I can tell.
>
> I can only guess that these people configured a firewall that does not
> allow NTP replies back in and that made me wonder if NTPD should be more
> vocal about not getting responses after a couple of days ?
>
> The other thing i the one hour limit on startup, the top three on
> the list may be bitten by this.  I think we should remove that limit.
>
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by
incompetence.
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers



More information about the hackers mailing list