I'm trying to set up an ntpd server for my home network, but for some reason
ntpd decides that it is stratum 16 and does not synchronize:

ntpq> readlist
status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.1.1b@1.829 Fri Sep 26 21:41:19 EST 2003 (1)",
processor="i686", system="Linux2.4.20-xfs-r3", leap=11, stratum=16,
precision=-17, rootdelay=0.000, rootdispersion=9.060, peer=0,
refid=0.0.0.0, reftime=00000000.00000000  Thu, Feb  7 2036  1:28:16.000,
poll=4, clock=c321da06.51a261bf  Sun, Sep 28 2003 17:07:02.318, state=0,
offset=0.000, frequency=0.000, jitter=0.008, stability=0.000

The log has nothing useful:

28 Sep 16:56:57 ntpd[23564]: signal_no_reset: signal 17 had flags 4000000

And I am completely mystified. Maybe refid of 0.0.0.0 has something to do
with it? Isn't that supposed to be my IP?

-Matt

"Matt Taylor" <para@tampabay.rr.com> writes:
> I'm trying to set up an ntpd server for my home network, but for some reason
> ntpd decides that it is stratum 16 and does not synchronize:

As always, "What is the output of 'ntpdq -p'?"

Dale

"Dale Worley" <worley@dragon.ariadne.com> wrote in message
news:87n0cooa8j.fsf@netnews.comcast.net...
> "Matt Taylor" <para@tampabay.rr.com> writes:
> > I'm trying to set up an ntpd server for my home network, but for some
reason
> > ntpd decides that it is stratum 16 and does not synchronize:
>
> As always, "What is the output of 'ntpdq -p'?"
>
> Dale

I apparently don't have a program named ntpdq, and I don't see it mentioned
anywhere in the docs, but here is the output of ntpdc -p and ntpq -p:

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.

-Matt

"Matt Taylor" <para@tampabay.rr.com> schrieb
>
> I can't figure out why I would be rejected from an open stratum 2
server,
> though.
>

Hey,

whats happened if you try another server?

Hans

"Hans Klein" <newsartikel@web.de> wrote in message
news:bl8o43$9gavc$1@ID-206916.news.uni-berlin.de...
> "Matt Taylor" <para@tampabay.rr.com> schrieb
> >
> > I can't figure out why I would be rejected from an open stratum 2
> server,
> > though.
> >
>
> Hey,
>
> whats happened if you try another server?
>
> Hans

I have tried 4 different open stratum 2 servers and obtain the same response
from each. In all cases ntpdc shows packets being sent and received, but
ntpd does not synchronize to any of them.

I can synchronize just fine to these servers from a Windows machine NAT
through the other machine, so I do not think this is a networking issue.

ntpq> as
ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 50292  8000   yes   yes  none    reject
  2 50293  8000   yes   yes  none    reject
  3 50294  8000   yes   yes  none    reject
  4 50295  8000   yes   yes  none    reject

I think the "reject" bit there is probably the key, but I'm lost as to what
would cause my client to be rejected.

The docs offer this advice:

"If both the sent and received counters do increment, but the reach values
in the pe billboard with ntpq continues to show zero, received packets are
probably being discarded for some reason. If this is the case, the cause
should be evident from the flash variable as discussed above and on the ntpq
page. It could be that the server has disabled access for the client
address, in which case the refid field in the ntpq pe billboard will show a
kiss code. See earlier on this page for a list of kiss codes and their
meaning."

I get no kiss code, and the flash variable is 00.

-Matt

"Matt Taylor" <para@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

"Dale Worley" <worley@dragon.ariadne.com> wrote in message
news:873cefohe8.fsf@netnews.comcast.net...
> "Matt Taylor" <para@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

> Seems to me that ntpd would use UTC.
>
> -Matt

It does.

It is up to your OS to display the time correctly from the internal UTC
format, i.e. it is up to you to ensure your time zone is correctly set.

Windows and UNIX handle the BIOS clock differently, so the appropriate
setting at the CMOS prompt will differ.  In Windows, you set the "clock"
time appropriate for your chosen time zone.

Cheers,
David

On Mon, 29 Sep 2003 14:13:03 GMT, Matt Taylor wrote:
> "Dale Worley" <worley@dragon.ariadne.com> wrote in message
> news:873cefohe8.fsf@netnews.comcast.net...
>> "Matt Taylor" <para@tampabay.rr.com> writes:
> 
> 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
Try changing ignore to noquery
/hjj

"David J Taylor" <david-taylor@blueyonder.co.uk> wrote in message
news:6SXdb.3605$nN7.31822951@news-text.cableinet.net...
<snip>
> It is up to your OS to display the time correctly from the internal UTC
> format, i.e. it is up to you to ensure your time zone is correctly set.
<snip>

Daylight savings. Argh. I was set to EST, not EDT. Thanks.

-Matt

"Hans J�rgen Jakobsen" <hjj@wheel.dk> wrote in message
news:slrnbngl2d.1am6.hjj@freesbee.wheel.dk...
> On Mon, 29 Sep 2003 14:13:03 GMT, Matt Taylor wrote:
> > "Dale Worley" <worley@dragon.ariadne.com> wrote in message
> > news:873cefohe8.fsf@netnews.comcast.net...
> >> "Matt Taylor" <para@tampabay.rr.com> writes:
> >
> > 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
> Try changing ignore to noquery
> /hjj

NTP seems to be working now. Thanks to all who replied. I appreciate the
help.

-Matt

"Matt Taylor" <para@tampabay.rr.com> writes:
> 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.

Yes, that is completely correct.  The trouble is that it applies to
*all* incoming packets, even those that are responses from your NTP's
requests to the servers you specify in ntp.conf.  You have to
un-restrict them, one way or another.

Dale