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/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 ---- continue; /* Reset this because icp just changed... */ + #ifndef icmp_data icp_time = (time_t *)(icp + 1); + #else + icp_time = (time_t *)icp->icmp_data; + #endif sendtime = ntohl(icp_time[0]); 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 instead.