[ntp:bugs] [Bug 434] Event clk_fault for refclocks at ntpd startup

[bugzilla at ntp.isc.org]

http://bugs.ntp.isc.org/show_bug.cgi?id=434





------- Additional Comments From kardel at ntp.org  2005-05-28 10:16 -------
Looking further into the code I find:

peer->leap = LEAPNOTSYNC is set in clear_peer().
At startup clear_peer(peer, "INIT") is called for refclocks.
leap is set because the FLAG_REFCLOCK flag is not set yet as
refclock_newpeer has not been called yet. After
refclock_newpeer is called clear_peer will leave peer->leap
as it is. The ONLY place left fiddeling with peer->leap for
refclocks is refclock_receive. In refclock_receive() we find following segment:

if (peer->leap == LEAP_NOTINSYNC || pp->leap == LEAP_NOTINSYNC)
	refclock_report(peer, CEVNT_FAULT);
peer->leap = pp->leap;

We know that peer_leap can be LEAPNOTINSYNC from startup (peer_clear when
FLAG_REFCLOCK is not set yet) or from the line above.
Thus interrogating peer->leap only gives a a false reclock_report from
initialization. False in that respect that new knowledge is available
(pp->leap) and will be the current information from then on.

The peer->leap test should be removed. The pp->leap test is ok in order to
make sure that refclock reported LEAPNOTINSYNCs lead to a CEVNT_FAULT
report.

Fix will be in pogo:~kardel/ntp-dev

BTW: the following reflocks seem to manipulate peer->leap directly (grep for
peer->leap):
refclock_oncore.c
  This driver also does not seem to have a LEAPNOTINSYNC indication (bug?).
refclock_wwv.c
  This driver uses pp->leap and peer-> leap (consistency check?)



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.