refid on client differs from refid on local server

refid on client differs from refid on local server

Post by David L. M » Mon, 19 Dec 2005 02:48:06


Danny,

The ntpq already does display one of the "other" types, in particular if
a reference clock or kiss code is involved. This was a recent change to
avoid the misleading IP address for reference clocks operated at an
elevated stratum. Note that in orphan mode the refid displayed is the
loopback address, but this is entirely legit.

Dave
 
 
 

refid on client differs from refid on local server

Post by David L. M » Tue, 20 Dec 2005 06:32:12

Danny,

You are concerned about the reference ID display in ntpq when a remote
client of a local server has synchronized to an IPv6 server. Whether the
hash of the client destination address matches the reference ID in the
packet, thus confirming a loop, is not the issue. The issue is what to
tell the ntpq monitor program. It was the intent to send raw data to
ntpq that could be displayed directly, although ntpq usually cooks it.
So, the ntpd program has the choice on how to format the field. But,
ntpd does not know whether the reference ID field is an IPv4 address or
hash of an IPv6 address.

There are a couple of simple things that could be done. If a loop is
detected, ntpd knows the address family. If not, try the autocorrelation
function, which should be flat for a good hash and probably peaky for a
legitimate IPv4 address. In today's Internet with dense 32-bit address
space, that might have a poor hit rate. What is needed is a little
steganography, so plant bits in the hash that can be detected by the
local server.

Here's a way this could work. The client knows when a loop can occur, so
in that case operate as prescribed. If a loop does not occur and the
client is synchronized to another IPv6 source, the hash won't match. In
that case hijack the reference ID field to a defined but unlikely value
that the local server can recognize. An all-zero value comes to mind.
What that means to the local server is that the client is synchronized
to another IPv6 source, so the local server can send a fake reference ID
of "IPv6" to the ntpq program.

I have no problem with this and it does conform to the design intent. I
wonder if this is making to fine a point on the display interpretation.

Dave