[ntp:questions] Re: NTP Stratum 16?

Matt Taylor para at tampabay.rr.com
Mon Sep 29 14:13:03 UTC 2003

"Dale Worley" <worley at dragon.ariadne.com> wrote in message
news:873cefohe8.fsf at netnews.comcast.net...
> "Matt Taylor" <para at tampabay.rr.com> writes:
> > humptydumpty net # ntpq -p -n
> >      remote           refid      st t when poll reach   delay   offset
> > jitter
> >
> > ==
> >         16 u    -   64    0    0.000    0.000
> > 4000.00
> >
> > humptydumpty net # ntpdc -p -n
> >      remote           local      st poll reach  delay   offset    disp
> > =======================================================================
> > =         16   64    0 0.00000  0.000000 0.00000
> >
> > I'm getting packets back, but no kiss code. I did notice this, too:
> >
> > ntpq> as
> > ind assID status  conf reach auth condition  last_event cnt
> > ===========================================================
> >   1  3052  8000   yes   yes  none    reject
> >
> > I can't figure out why I would be rejected from an open stratum 2
> > though.
> Checking the 'as' output for my NTP daemon, it marks some associations
> as 'reject' also.  My guess is that it's not your daemon getting
> rejected by the server, but your daemon is rejecting whatever it's
> getting from the server.
> Given that 'last_event' is blank and 'reach' is zero, it looks like
> your daemon is deciding that the packets from are bogus.
> I just synced my daemon to with no trouble, so I'd guess
> that you've got some sort of authentication going and
> doesn't pass it.
> You might want to try an assortment of other servers temporarily, and
> see if you get different results from different servers, or the same.
> Dale

I did try other servers and got the same results. I found the culprit. It
seems that a combination of factors caused the failure. First, entries in my

restrict default ignore
restrict mask notrust nomodify notrap
restrict mask notrust nomodify notrap
restrict mask notrust nomodify notrap

My understanding was that this applied toward clients and would restrict
traffic to well-known, private subnets. Everyone trying to sync to me from
the outside would get blocked by the default rule.

The other thing was that I needed the -g flag. It decided that my clock was
an hour fast, so I guess it was rejecting the servers because the difference
was too large. I left it running for a day, but it just sat there doing
nothing. Now that it's synchronized my clock, my clock is an hour slow. The
server I am syncing with is on CST and I'm on EST, but that wouldn't cause
problems, would it? Seems to me that ntpd would use UTC.


More information about the questions mailing list