[ntpwg] Re: peer flash bits

[David L. Mills]

Harlan,

Your list is incomplete. There are now 13 flash bits. The ones that 
moved were lit incorrectly, both in label and in function. The current 
flashers are in two groups: the first nine show the status of the last 
packet processed and the last four show the state of the association. It 
is important that this distinction be preserved, as some of the values 
monitored, especially the distance, change at times other than the 
arrival of a packet. This distinction was not made previously.

The flash code is conveyed in a packet format consistent with the NTPv3 
specification and expected to continue in the NTPv4 specification. This 
format is in prettyprint ASCII with named fields name=value. The flash 
bits themselves have not been defined in any specification. They are 
considered only a debugging tool and as such will change as 
specification and implementation evolve. The other data in the packet 
have changed over time and are expected to change in future. Somebody 
might write a MIB for NTP, but I intend the NTP monitoring data to be 
much more dynamic than usually expected in a MIB.

The only place the flashers appear now is on the ntpq peer billboard, 
where they are accompanied by tattletales intended for quick helpdesk 
evaluation. There is no need to interpret the bits themselves other than 
in the source code as I have done. The ntpq program itself was not part 
of the NTPv3 specification and will not be a part of the NTPv4 
specification.

As for backward compatibility, there are dozens of evil little places 
where the NTPv3 (xntpd) and NTPv4 (ntpd) monitoring tools of one version 
display incorrect, misleading or inconsistent values when used with 
another version. I'm interested in maintaining backward compatibility, 
but not to the level of detail here. An ntpq v3 decode of the ntpd v4 
flash bits already was incorrect even before the recent change.

The version number is in every NTP packet. It's the first four bits in 
the packet consistent with common Internet practice. You will notice the 
ntpq program already has sideways compatibility with the Fuzzball v2 
implementation.

Dave

Harlan Stenn wrote:

>
>
>In ntp3, the peer flash bits were:
>
>#define TEST1           0x01    /* duplicate packet received */
>#define TEST2           0x02    /* bogus packet received */
>#define TEST3           0x04    /* protocol unsynchronized */
>#define TEST4           0x08    /* peer delay/dispersion bounds check */
>#define TEST5           0x10    /* peer authentication failed */
>#define TEST6           0x20    /* peer clock unsynchronized */
>#define TEST7           0x40    /* peer stratum out of bounds */
>#define TEST8           0x80    /* root delay/dispersion bounds check */
>
>In ntp4, the bits became:
>
>#define TEST1           0x0001  /* duplicate packet received */
>#define TEST2           0x0002  /* bogus packet received */
>#define TEST3           0x0004  /* protocol unsynchronized */
>#define TEST4           0x0008  /* access denied or crypto failure */
>#define TEST5           0x0010  /* MAC error */
>#define TEST6           0x0020  /* peer clock unsynchronized */
>#define TEST7           0x0040  /* peer stratum out of bounds */
>#define TEST8           0x0080  /* root delay/dispersion bounds check */
>#define TEST9           0x0100  /* peer delay/dispersion bounds check */
>#define TEST10          0x0200  /* autokey error */
>#define TEST11          0x0400  /* protocol error */
>
>It is Bad that peer delay/dispersion moved.  ntpq gets these values in
>a hex field and there seems to be no version information in the packet to
>indicate how the bits should be decoded.
>
>Dave has just updated this code again and his new code has:
>
>#define TEST1           0x0001  /* duplicate packet */
>#define TEST2           0x0002  /* bogus packet */
>#define TEST3           0x0004  /* invalid timestamp */
>#define TEST4           0x0008  /* access denied */
>#define TEST5           0x0010  /* authentication error */
>#define TEST6           0x0020  /* peer not synchronized */
>#define TEST7           0x0040  /* invalid distance */
>#define TEST8           0x0080  /* autokey error */
>#define TEST9           0x0100  /* crypto error */
>
>and some of the bits have moved again.
>
>I belive that this is Bad, as we have no way to properly decode the flash
>condition.
>
>I think we should:
>
>- make the new bits backward-compatible to the extent possible.
>- get version information into these packets
>- consider having ntpd send back decoded strings instead of bit strings
>  for mode 6 (and mode 7) requests
>
>We're gonna need to advertise the current problem, as different versions
>of ntpq will decode (at least) the flash value differently.
>
>H
>