[ntp:questions] ntpdate.c unsafe buffer write
david at ex.djwhome.demon.co.uk.invalid
Sun Feb 10 10:55:29 UTC 2008
Harlan Stenn wrote:
> In the case I describe, at the end of that O(11 second) period the clock is
> Real Close (ie, the offset is "low enough"), the frequency drift is known
> and compensated for, and ntpd is in "state 4".
As I read 4.2.4p4, for a warm start, the clock is within 128ms on exit.
However, if it wasn't stepped, because it was already within 128ms, it
will be slewing at maximum rate. Allowing 100ppm for motherboard
tolerances, that means that it can take up to a further 320 seconds to
reach the low milliseconds. I don't believe it would be safe to start
ntpd in normal mode within that period.
For a cold start, it won't reach state 4 for a further 900 seconds after
first priming the clock filter.
The 128ms is the tinkerable clock_max value, so it would be possible to
configure for a tighter tolerance, but that probably means using
different config files for start and run. The 900 is also the
tinkerable clock_minstep. Note that setting clock_max to zero really
sets it to infinity.
Tinkering comes with the comment:
Special tinker variables for Ulrich Windl. Very dangerous.
The best advice for someone trying to simulate ntpdate -b is probably to
make sure that the clock is wrong by at least 128ms before starting.
That way, you should get a step, even with the default configuration.
More information about the questions