Hi,

It looks like ntp-4.1.80.r1 screws up IPv6 refid's internally.

If you look at the appended ntpq output, you will see that:

- sanne.nlnetlabs.nl sync's with the IPv6 address from
  "bohr.nlnetlabs.nl" (2001:7b8:206:1:240:f4ff:fe37:8232,
  but truncated to "2001:7b8:206:1:" on the ntpq -pn output).
- However, "ntpq -crv" tells us that the refid=210.172.193.153.
  This looks like an ipv4 number, but it is really bogus.
- Looking at another host (in this case open.nlnetlabs.nl)
  we also see that sanne.nlnetlabs.nl seems to have this
  bogus refid.

<ted@sanne:23>> ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-omval.tednet.nl 192.16.190.34    2 u    5   64  356    0.004   11.576   3.646
*bohr.nlnetlabs. .DCFa.           1 u  825 1024  377    0.368    6.262   3.150
+open.nlnetlabs. 193.67.79.202    2 u  383 1024  377    0.417    8.063   2.281
+floep.nlnetlabs 213.154.224.17   2 u  859 1024  377    0.528    7.441   2.071
<ted@sanne:24>> ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-213.154.224.17  192.16.190.34    2 u    8   64  356    0.004   11.576   3.646
*2001:7b8:206:1: .DCFa.           1 u  828 1024  377    0.368    6.262   3.150
+2001:7b8:206:1: 193.67.79.202    2 u  386 1024  377    0.417    8.063   2.281
+2001:7b8:206:1: 213.154.224.17   2 u  862 1024  377    0.528    7.441   2.071
<ted@sanne:25>> ntpq -crv
status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.1.80-rc1-r Tue Jul  8 13:26:33 CEST 2003 (1)",
processor="i386", system="FreeBSD/5.1-CURRENT", leap=00, stratum=2,
precision=-18, rootdelay=0.368, rootdispersion=79.421, peer=28685,
refid=210.172.193.153,
reftime=c2ca5e94.03c1b45d  Thu, Jul 24 2003 15:33:08.014, poll=10,
clock=c2ca61d3.d5ac9240  Thu, Jul 24 2003 15:46:59.834, state=4,
offset=4.850, frequency=9.265, jitter=4.447, stability=0.414
<ted@sanne:26>> ntpq -p open
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        73.78.73.84      5 l   33   64  377    0.000    0.000   0.004
*ntp0.NL.net     .GPS.            1 u  547 1024  377   13.788    3.374   1.592
+tt01.ripe.net   .GPS.            1 u  946 1024  377    1.133    0.539   0.168
-omval.tednet.nl 192.16.190.34    2 u   23   64  356    0.004    2.669   2.617
-sanne.nlnetlabs 210.172.193.153  2 u  403 1024  376    2.720   -6.912   2.354
+floep.nlnetlabs 213.154.224.17   3 u  639 1024  377    0.473    2.454   0.236
<ted@sanne:27>> 

Regards,
-- ted

In article <bfrmi6$lri$3@osl016lin.hda.hydro.com>,
Terje Mathisen  <terje.mathisen@hda.hydro.com> wrote:

>Today a refid is instead a cryptographically strong hash, since the only 
>important use of it is to detect synchronization loops.

Management is no less important, and crypto hashes don't help there.

-GAWollman

-- 
Garrett A. Wollman   | As the Constitution endures, persons in every
wollman@lcs.mit.edu  | generation can invoke its principles in their own
Opinions not those of| search for greater freedom.
MIT, LCS, CRS, or NSA| - A. Kennedy, Lawrence v. Texas, 539 U.S. ___ (2003)

Terje,

The obscure hash should occur only with IPv6 addreses and reference 
identifiers, not with IPv4 addresses and reference clocks. There might 
be some wiggle room in the current distribution that should be fixed.

Dave

Terje Mathisen wrote:
> Ted Lindgreen wrote:
> 
>> Hi,
>>
>> It looks like ntp-4.1.80.r1 screws up IPv6 refid's internally.
>>
>> If you look at the appended ntpq output, you will see that:
>>
>> - sanne.nlnetlabs.nl sync's with the IPv6 address from
>>   "bohr.nlnetlabs.nl" (2001:7b8:206:1:240:f4ff:fe37:8232,
>>   but truncated to "2001:7b8:206:1:" on the ntpq -pn output).
>> - However, "ntpq -crv" tells us that the refid=210.172.193.153.
>>   This looks like an ipv4 number, but it is really bogus.
>> - Looking at another host (in this case open.nlnetlabs.nl)
>>   we also see that sanne.nlnetlabs.nl seems to have this
>>   bogus refid.
> 
> 
> IPv6 have forced us to remove the old, very nice, feature where refid's 
> were simply IPv4 addresses (127.* in the case of refclocks).
> 
> Today a refid is instead a cryptographically strong hash, since the only 
> important use of it is to detect synchronization loops.
> 
> Terje