[ntp:questions] Re: NTP Stratum 16?
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
> > ==
> > 22.214.171.124 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
> > =======================================================================
> > =126.96.36.199 188.8.131.52 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 184.108.40.206 are bogus.
> I just synced my daemon to 220.127.116.11 with no trouble, so I'd guess
> that you've got some sort of authentication going and 18.104.22.168
> 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.
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 192.168.0.0 mask 255.255.0.0 notrust nomodify notrap
restrict 22.214.171.124 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.
More information about the questions