ntpq output truncates IPv6 addresses

Forwarded from Ubuntu bug report #325111:

'Running ntpq with the -n (numeric) flag causes ntpq to print raw IP addresses
rather than perform DNS lookups. When an IPv6 peer is present, the IPv6 address
is truncated, hiding the right-most digits.

Proper operation would be to show the entire IPv6 address.

Example output:

# ntpq -n
ntpq> peers
     remote refid st t when poll reach delay offset jitter
==============================================================================
+2001:1111:111:2 69.10.36.6 3 u 15 64 377 0.304 0.668 1.072
+91.189.94.4 193.79.237.14 2 u 23 128 377 108.365 -1.872 2.214

The first peer (actual address changed somewhat but formatting unaltered) has
been truncated after ":2".'

For ease of reference, I'm including a URL to the Web-viewable patches applied
to the version of ntp (1:4.2.4p4+dfsg-7ubuntu3) in Ubuntu 9.04 ("jaunty"):
http://package-import.ubuntu.com/n/ntp/jaunty/files/head%3A/debian/patches/

Please attach the suggested patch to this bug report.

This is a known issue in ntp with IPv6 addresses since the row will no longer
fit into 80 characters, the standard size for standard output.

Danny

FYI, the full IPv6 address is visible using rv/readvar:

ntpq -npc "rv &2"

will show all the variables ntpd sends to ntpq for the second association in the billboard. ntpq summarizes this information in the peers billboard single-line representation.

Realistically, any fix to this problem would most likely involve yet another billboard variation, with a wider "remote" column by losing some other column(s).

Dave Hart,

Were you and I discussing ways to show wider output for ntpq? I'm trying to remember if we were going to consider -w/--wide or if we were thinking being able to specify -w/--width=NN was better.

A thought:

Cisco IOS (routers) solved this by putting IPv6 addresses on their own line,
then indenting the following line so that the columns line up.

This is pretty easy for scripts that parse the output to accomodate, and visually it works, at least for me.

And since they have deployed a solution, it would be nice to be consistent....

(I'm not affiliated with cisco, but I am a user.)

Oh, here's a sample:

router#show ntp assoc

  address ref clock st when poll reach delay offset disp
-~2600:3C03::F03C:91FF:FEDF:9B84
                  128.4.40.12 3 265 512 377 43.274 10.649 0.032
 ~149.20.68.17 .INIT. 16 - 1024 0 0.000 0.000 15937.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Good idea, and the "problem" is the refid is a 32-bit structure.

Its purpose is for loop detection - to make sure machine A doesn't
believe time from machine B if machine B is getting its time from A.

I've had some chats with Prof. Mills about this and we're gently
discussing changing the refid value for non-refclock sources to a simple
nonce.

(In reply to comment #7)
> Good idea, and the "problem" is the refid is a 32-bit structure.
>
> Its purpose is for loop detection - to make sure machine A doesn't
> believe time from machine B if machine B is getting its time from A.
>
> I've had some chats with Prof. Mills about this and we're gently
> discussing changing the refid value for non-refclock sources to a simple
> nonce.

That's a separate issue from displaying the full server address. I actually have some where a subnet has the several servers, and I can't tell them apart; the initial part of the IP address matches several machines, and some machines have both A and AAAA records...so the names aren't unique either. it isn't pretty.

As far as the reference address - I thought that for IPv6, the refid was a hash of the IPv6 address - which means it's already a nonce. There's some small probability of a collision (2 + n in 4 billion - 1 for IPv4 and 1 for IPv6 + the possibility that an IP address or hash turns out to be one of the refclock tags - e.g. .GPS., .PPS., .INIT etc - in binary).

Now that bits are cheaper, perhaps NTPv5 can allocate 136 bits -- 8 for an entity id (IPv4 address, IPv6 address, and Refclock to start with) + a full IPv6 address at the end of the packet. Oooh - NTPv5? Well, maybe not. Just think of all the firewalls and other chaos ;-)

In any case, displaying the full server IP address would be a big help.

I don't have a strong opinion on whether the expanded format should require a command-line switch - such as -w. IPv6 will require any scripts that parse the text to change anyway - and humans won't care. But it would be a way to guarantee backward compatibility.

Anyhow, after 4 years, it would be nice to see this addressed...IPv6 IS gathering steam.

Thanks.