[ntp:questions] Conflicting information on packet field types

Steven Sommars stevesommarsntp at gmail.com
Fri Nov 2 03:29:03 UTC 2018


On the poll field.   Earlier RFCs are obsoleted by RFC5905, plus there are
some terminology changes/errors when comparing documents.
Even staying within RFC5905 terminology can be inconsistent:  it contains a
mixture of "on-the-wire" data field definitions, algorithms, and code.

My interpretation:  Looking at an "on-the-wire" NTP packet the "poll" field
should be interpreted as signed:

 Poll: 8-bit signed integer representing the maximum interval between
   successive messages, in log2 seconds.  Suggested default limits for
   minimum and maximum poll intervals are 6 and 10, respectively.


A poll value of 6 corresponds to a "poll interval" of 64 seconds (log2(64)
is 6); poll interval is unsigned and can be larger than 8 bits.

I don't believe the reference NTP software (ntp.org) supports negative
values of poll, so signed versus unsigned issues don't arise.

Chrony, another NTP implementation, does support negative values of poll.

On Thu, Nov 1, 2018 at 3:40 AM Jason Rabel <jasonrabel99 at gmail.com> wrote:

> I was mainly reading RFC 5905 since it's the latest, but it does make
> some references back to the older RFC 4330 (SNTP). I believe it is
> that document (and others) that seem to flip-flop on what is signed /
> unsigned. i.e. 5905 says poll interval is signed, 4330 says poll
> interval is unsigned.
>
> I dug around in the NTP source (4.2.8p12), specifically in the
> include/ntp.h file there seems to be the various structures...
>
> In the peer struct, which the comment says, "The peer structure. Holds
> state information relating to the guys we are peering with. Most of
> this stuff is from section 3.2 of the spec."
>
> u_char ppoll; /* remote poll interval */
> double rootdelay; /* roundtrip delay to primary source */
> double rootdisp; /* dispersion to primary source */
>
> But further down in the pkt struct, which the comment says, "NTP packet
> format."
>
> u_char ppoll; /* peer poll interval */
> u_fp rootdelay; /* roundtrip delay to primary source */
> u_fp rootdisp; /* dispersion to primary source*/
>
> Poll interval is unsigned in both instances, even though the RFC says
> it should (could) be signed? Again, nothing in the standard NTP
> distribution would lead me to believe any negative number would ever
> be sent, but with other time packages out there, who knows? TBH, I'm
> not really sure what purpose sending the 'poll interval' really serves
> in a client/server scenario (probably none). Maybe in a peer setup it
> might hint something? I'm curious how NTP handles it, just not curious
> enough to go digging through thousands of lines of code, lol.
>
> Jumping now from Root Dispersion (which we seem to agree on is
> unsigned) to Root Delay.... RFC 5905 is pretty vague on "Root Delay",
> only saying it is "NTP Short Format", and like you quoted below it
> *should* be unsigned.
>
> However, RFC 4330 goes a little more in-depth saying, "This is a
> 32-bit signed fixed-point number indicating the total roundtrip delay
> to the primary reference source, in seconds with the fraction point
> between bits 15 and 16.  Note that this variable can take on both
> positive and negative values, depending on the relative time and
> frequency offsets.  This field is significant only in server messages,
> where the values range from negative values of a few milliseconds to
> positive values of several hundred milliseconds."
>
> But to contradict even that, later in RFC 4330 there is a blurb about,
> "A truly paranoid client can check that the Root Delay and Root
> Dispersion fields are each greater than or equal to 0 and less than
> infinity, where infinity is currently a cozy number like one second."
>
> I found this blurb about the delay computation, "In some scenarios
> where the initial frequency offset of the client is relatively large
> and the actual propagation time small, it is possible for the delay
> computation to become negative.  For instance, if the frequency
> difference is 100 ppm and the interval T4-T1 is 64 s, the apparent
> delay is -6.4 ms.  Since negative values are misleading in subsequent
> computations, the value of delta should be clamped not less than
> s.rho, where s.rho is the system precision described in Section 11.1,
> expressed in seconds."
>
> I know this is all a bunch of 'what if' scenarios that probably will
> never happen... Especially with the packet NTP sends out apparently is
> unsigned for root delay. But again my thoughts are about other time
> programs out there. I'm going to take a wild guess and say that (under
> normal circumstances) if NTP (or any time program) is calculating a
> negative delay (and likely a huge time offset), it's probably also
> considering itself unsynced and won't send out time to any clients
> that request it until things normalize.
>
> Jason
>
>
> > The RFC 5905 (NTPv4) should be the authoritative source here. For the
> > poll field it has:
> >
> >  8-bit signed integer representing the maximum interval between
> >  successive messages, in log2 seconds.
> >
> > For the root dispersion there is:
> >
> >  The 32-bit short format is used in delay and dispersion header fields
> >  where the full resolution and range of the other formats are not
> >  justified.  It includes a 16-bit unsigned seconds field and a 16-bit
> >  fraction field.
> >
> > So, poll is signed and root dispersion is unsigned.
> >
> > Which documents have conflicting information? I think ntpd internally
> > uses an "unsigned" poll variable, but I'm not sure if it really is an
> > issue as it doesn't support sub-second polling intervals.
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>


More information about the questions mailing list