[ntp:questions] bug in ntp-stable-4.2.0a-20060224 on clock field output by ntpq -c rv
degiy at yahoo.fr
degiy at yahoo.fr
Thu Apr 13 13:54:06 UTC 2006
I found a bug in ntp-stable-4.2.0a-20060224 :
A ntpq - c rv command outputs :
assID=0 status=0644 leap_none, sync_ntp, 4 events,
event_peer/strat_chg,
version="ntpd 4.2.0a at 1.1190-r Fri May 27 08:11:20 CEST 2005 (1)"?,
processor="i686", system="Linux/2.6.14-prep", leap=00, stratum=2,
precision=-20, rootdelay=1.824, rootdispersion=44.238, peer=55212,
refid=10.17.1.111,
reftime=c7e8d04d.2a788db0 Thu, Apr 13 2006 15:27:41.165, poll=8,
clock=0xc7e8d054.f032a8c9, state=4, offset=25.492, frequency=-40.575,
<= this line
noise=4.358, jitter=6.982, stability=217.401
My previous version (4.1.0) used to output :
status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
version="ntpd 4.1.0 Thu May 12 17:23:26 CEST 2005 (1)",
processor="i686", system="Linux2.4.30-8", leap=00, stratum=2,
precision=-17, rootdelay=2.853, rootdispersion=37.114, peer=17013,
refid=ntp1, reftime=c7e8cf63.004bf4cb Thu, Apr 13 2006 15:23:47.001,
poll=10, clock=c7e8d27b.0afd976f Thu, Apr 13 2006 15:36:59.042,
<= this line
state=4, offset=0.183, frequency=-38.532, jitter=2.951, stability=0.003
So to focus just on clock field :
clock=0xc7e8d054.f032a8c9
instead of
clock=c7e8d27b.0afd976f Thu, Apr 13 2006 15:36:59.042
The clock format seems wrong, assuming it shoud be in the same syntax
as reftime, literally "time stamp" if I believe what is written in
ntpq.c :
struct ctl_var sys_var[] = {
{ 0, PADDING, "" }, /* 0 */
{ CS_LEAP, LP, "leap" }, /* 1 */
{ CS_STRATUM, UI, "stratum" }, /* 2 */
{ CS_PRECISION, SI, "precision" }, /* 3 */
{ CS_ROOTDELAY, FS, "rootdelay" }, /* 4 */
{ CS_ROOTDISPERSION, FU, "rootdispersion" }, /* 5 */
{ CS_REFID, RF, "refid" }, /* 6 */
{ CS_REFTIME, TS, "reftime" }, /* 7 */
{ CS_POLL, UI, "poll" }, /* 8 */
{ CS_PEERID, UI, "peer" }, /* 9 */
{ CS_STATE, UI, "state" }, /* 10 */
{ CS_OFFSET, FL, "offset" }, /* 11 */
{ CS_DRIFT, FS, "frequency" }, /* 12 */
{ CS_JITTER, FU, "jitter" }, /* 13 */
{ CS_CLOCK, TS, "clock" }, /* 14 */
{ CS_PROCESSOR, ST, "processor" }, /* 15 */
{ CS_SYSTEM, ST, "system" }, /* 16 */
{ CS_VERSION, ST, "version" }, /* 17 */
{ CS_STABIL, FS, "stability" }, /* 18 */
{ CS_VARLIST, ST, "sys_var_list" }, /* 19 */
{ 0, EOV, "" }
};
The bug seems to be that
CS_CLOCK worth 15 and no longer 14 due to the "noise" field addition in
this ntp version
../include/ntp_control.h:162:#define CS_CLOCK 15
static struct ctl_var sys_var[] = {
{ 0, PADDING, "" }, /* 0 */
{ CS_LEAP, RW, "leap" }, /* 1 */
{ CS_STRATUM, RO, "stratum" }, /* 2 */
{ CS_PRECISION, RO, "precision" }, /* 3 */
{ CS_ROOTDELAY, RO, "rootdelay" }, /* 4 */
{ CS_ROOTDISPERSION, RO, "rootdispersion" }, /* 5 */
{ CS_REFID, RO, "refid" }, /* 6 */
{ CS_REFTIME, RO, "reftime" }, /* 7 */
{ CS_POLL, RO, "poll" }, /* 8 */
{ CS_PEERID, RO, "peer" }, /* 9 */
{ CS_STATE, RO, "state" }, /* 10 */
{ CS_OFFSET, RO, "offset" }, /* 11 */
{ CS_DRIFT, RO, "frequency" }, /* 12 */
{ CS_JITTER, RO, "jitter" }, /* 13 */
{ CS_ERROR, RO, "noise" }, /* 14 */ <=
addition
{ CS_CLOCK, RO, "clock" }, /* 15 */
{ CS_PROCESSOR, RO, "processor" }, /* 16 */
... and so on
The problem is that the "findvar" function :
2765 while (vl->fmt != EOV) {
2766 if (vl->fmt != PADDING && STREQ(np, vl->text))
2767 return vl->code;
returns "vl->code" (explicitely 15 for clock) and that the calling
function "cookedprint" uses this value (varid=15) to access the
structures of the varlist table:
3031 varid = findvar(name, varlist);
3032 if (varid == 0) {
3033 output_raw = '*';
3034 } else {
3035 output_raw = 0;
3036 fmt = varlist[varid].fmt;
guess what is then use, the next line in the table, which explain the
raw output:
(gdb) print varlist[varid]
$15 = {code = 16, fmt = 9, text = 0x805380c "processor"}
why ? because the "noise" line is missing. My solution was to add the
"noise" line into the ctl_var sys_var table.
Then I get :
./ntpq -c rv
assID=0 status=0644 leap_none, sync_ntp, 4 events,
event_peer/strat_chg,
version="ntpd 4.2.0a at 1.1190-r Fri May 27 08:11:20 CEST 2005 (1)",
processor="i686", system="Linux/2.6.14-prep", leap=00, stratum=2,
precision=-20, rootdelay=1.293, rootdispersion=39.813, peer=55212,
refid=10.17.1.111,
reftime=c7e8d5d2.36ea4228 Thu, Apr 13 2006 15:51:14.214, poll=7,
clock=c7e8d624.40cf398e Thu, Apr 13 2006 15:52:36.253, state=4, <=
same as before
offset=23.800, frequency=-38.144, noise=3.182, jitter=3.818,
stability=200.909
Did someone else faced this bug, or is it already fixed in some newest
release ?
thanks for advance
jansou jerome
More information about the questions
mailing list