Miroslav,
My scenario did include the condition of eight valid sample before
pulling the plug The first missed poll response did result in one
MAXDISPERSE sample in the filter, but that is completely irrelevant. The
point is the poll routine calls clock_select() for every poll sent when
the last four samples in the reach register are missing, so it is
guaranteed that the server be marked down after that.
You are invited to peruse the code in ntp_proto.c and look for calls to
clock_select(). Note it is not possible to exit this routine without
either finding a system peer or declaring no system peer. See the calls
to report_event().
Dave
Miroslav Lichvar wrote:
On Fri, Jun 11, 2010 at 03:08:53AM +0000, David L. Mills wrote:
An hour later I disconnected the server. By second 4773 the server
became unreachable and was undeclared the system peer. ten minutes
later I reconnected the server which again became reachable and the
system peer.
You are missing the point. The bug doesn't show up if the clock
filter is filled with 8 valid samples before the connection is
blocked. There has to be at least one MAXDISPERSE sample (not the last
one).
Blocking the connection on ntpd start right after fourth reply was
recevied seems to trigger the bug reliably.
If you want to trigger it in a normal situation, you need to partially
flush the filter, let few valid samples in and then block the
connection pernamently. This doesn't work reliably and you might need
to retry it several times.
If you are using an old release version, that
might explain your results.
I can reproduce it with 4.2.6p1 and 4.2.7p32, I haven't tried
anything else.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
