[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
> >
============================================================================
> > ==
> >  128.105.37.11   0.0.0.0         16 u    -   64    0    0.000    0.000
> > 4000.00
> >
> > humptydumpty net # ntpdc -p -n
> >      remote           local      st poll reach  delay   offset    disp
> > =======================================================================
> > =128.105.37.11   5.0.0.0         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
server,
> > 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 128.105.37.11 are bogus.
> I just synced my daemon to 128.105.37.11 with no trouble, so I'd guess
> that you've got some sort of authentication going and 128.105.37.11
> 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
ntp.conf:

restrict default ignore
restrict 127.0.0.1
restrict 192.168.0.0 mask 255.255.0.0 notrust nomodify notrap
restrict 174.16.0.0 mask 255.240.0.0 notrust nomodify notrap
restrict 10.0.0.0 mask 255.0.0.0 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.

-Matt





More information about the questions mailing list