[ntp:bugs] [Bug 2136] NTPDC - results may be wrong against a remote 4.2.4p5 node

[bugzilla-daemon at ntp.org]

https://bugs.ntp.org/show_bug.cgi?id=2136

--- Comment #2 from Dave Hart <hart at ntp.org> 2012-02-09 12:37:06 UTC ---
> ntpdc uses binary structures on the wire, and assumes implicitly all
> systems have identical binary representations.  That works fine for
> integers, apparently not so well for floating-point. 

This is mistaken on my part -- all the data involved is in fact integer on the
wire, because the kernel NTP extensions do not using floating point.  The
on-wire structure is:


/*
 * Structure used for returning kernel pll/PPS information
 */
struct info_kernel {
    int32 offset;
    int32 freq;
    int32 maxerror;
    int32 esterror;
    u_short status;
    u_short shift;
    int32 constant;
    int32 precision;
    int32 tolerance;

/*
 * Variables used only if PPS signal discipline is implemented
 */
    int32 ppsfreq;
    int32 jitter;
    int32 stabil;
    int32 jitcnt;
    int32 calcnt;
    int32 errcnt;
    int32 stbcnt;
};

Values which are conceptually not integers are scaled by 1e-6 or 1e-9 for
display in ntpdc.  The default is 1e-6.  If the system where ntpdc is compiled
has NTP nanosecond-denominated kernel extensions (aka nanokernel, that is, if
STA_NANO is defined) and the status value has STA_NANO set, then the scale is
1e-9.  Result: mis-scaled numbers when querying a nanokernel-enabled system
from a non-nanokernel-compiled ntpdc (including microkernel like Solaris, and
"nonokerne" l like Windows).

Still the big picture is the same.  ntpdc kerninfo is particularly fragile and
should only be used between very similar systems.  ntpq kerninfo is robust. 
There is no reasonable way to fix this without seriously overhauling ntpdc and
ntpd, meaning the fix would only work with new ntpdc against new ntpd, and
given that ntpq gets it right, it doesn't make sense to re-engineer the
depracated ntpdc/ntpd mode 7 code.

-- 
Configure bugmail: https://bugs.ntp.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.