[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

Dave Hart <hart at ntp.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |hart at ntp.org
         Resolution|                            |WONTFIX

--- Comment #1 from Dave Hart <hart at ntp.org> 2012-02-09 12:20:52 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.  Further,
kerninfo in particular is horribly implemented in ntpdc, as the
decoding of the status bits depends on the client's kernel headers
related to NTP kernel extensions being identical between the system
where ntpdc was built and the system where ntpd was built -- meaning
you can get incorrect decoding querying between two systems which have
slightly different numeric values for some of the kernel NTP
bitfields, which should be a local implementation issue and not
presumed identifcal across all systems.  Here, Windows has no kernel
NTP extensions so it can decode none of the bits.  ntpq's kerninfo
repairs all these flaws -- it uses text representation of numbers on
the wire, so for both integer and floating-point types, there can be
no misunderstanding.  Further, ntpq's kerninfo relies on ntpd to
decode the flags bit values into flag names, so again it matters not
if ntpq was built on a system without kernel NTP extensions, or with
slightly different extensions.  In a few cases, the numbers are the
same but simply represented differently, simply because FreeBSD's
*printf() functions make different choices than Microsoft C about when
to use scientific notation given identical format strings and values.

All of these issues are known, and I don't believe any could be fixed
in ntpdc and ntpd without introducing new on-wire mode 7 operations,
which would work only with new ntpd and ntpdc.  All are fixed by new
ntpd and ntpq.

Once I send this mail I plan to paste this text into the recent bug
report filed for this issue, and resolve it indicating there will be
no fixes for these reasons.  I apologize for taking longer than usual
to respond -- real life intrusions combined with the flood of
questions@ list traffic when the newgroup gateway was fixed conspired
to overwhelm me.

Thanks for the report.

-- 
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.