Refclocks and formatting

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> There is another potential worm in this can.  I don't think if it applies to 
> this case, but it's worth keeping in mind.
> 
> Some of the flags that get decoded come from the kernel sources rather than 
> NTP sources.  They are generally the same across OSes and kernel versions, 
> but I don't know how to verify that.  I think the clean solution would be to 
> decode them on the server.  [Or copy the versions from one kernel to our 
> sources and have the build step crash if they are defined in the kernel and 
> different.)

You are right to raise this issue.  Either fix would be messy though.

Mode 6 should really not be shipping those flag bits in hex at all; it
should decode them into a list of mode strings. That would be the
*right* fix, but of course it would break mode 6 backward compatibility.

I'm tempted to do it anyway.  I'm normally extremely wary of doing things
that might break sysadmin scripts, but this is a rather improbable case -
somebody would have to be decoding those bits with a thing that isn't
ntpq or ntpmon itself to be affected.

We could keep the old behavior under ENABLE_CLASSIC_MODE.  Hm.  Hal,
what do you you think our actual risk exposure is here?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.