When fiddling with xntp and checking that hosts have the same time
I discovered that there is a bug in the timedc program. You can't
get a reasonable value when executing "timedc clockdiff <host>".
This was checked with version 5.2 till 6.1 where the bug exists.
I compiled the FreeBSD counterpart on RH 6.1 and this check runs as
expected (clockdiff functions).
Using timed-0.17-1.1 from RC1 clockdiff <host> with a two station network, one
being the master and one the slave only replies with <host> is down. However
turning trace on shows that the time demon is running on both machines and the
log shows that the master and the slave recognize each other.
The following patch will correct the problem. The corrected bug could also
cause a race condition when a Linux server was elected master server. This race
condition could have catastophic effects on system operation as the systems
continually adjust their time. I have had the system time advance by 5 years
within a ten minute interval. The actual time is being extracted from the wrong
point in the message by the measure() function in timed/lib/measure.c.
-------- cut-here: netkit-timed-0.16.patch ----------------
diff -rc netkit-timed-0.16-orig/timed/lib/measure.c
*** netkit-timed-0.16-orig/timed/lib/measure.c Mon May 19 05:41:37 1997
--- netkit-timed-0.16/timed/lib/measure.c Sun Sep 24 13:50:41 2000
*** 234,240 ****
--- 234,244 ----
/* Reset this because icp just changed... */
+ #ifndef icmp_data
icp_time = (time_t *)(icp + 1);
+ icp_time = (time_t *)icp->icmp_data;
sendtime = ntohl(icp_time);
recvtime = ((tcur.tv_sec % SECDAY) * 1000 +
-------- end cut -----------------
Apply from within netkit-timed-0.16 directory using
"patch -p1 < netkit-timed-0.16-patch"
we are obsoleting timed in our next release; many aspects of the protocol are
broken compared to ntp, and we are advocating users to use that solution