[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)

Martin Burnicki martin.burnicki at meinberg.de
Thu Feb 5 13:57:08 UTC 2009

Harlan Stenn wrote:
>>>> In article <u42o56-sji.ln1 at gateway.py.meinberg.de>, Martin Burnicki
>>>> <martin.burnicki at meinberg.de> writes:
> Martin> By default ntpdate sends and receives packets via port 123/UDP. It
> Martin> *only* sends via an unprivileged port if either -q (query only),
> -u
> Martin> (unpriv.  port), or -d (debug) is given on the command line.
> First, given that ntpdate is about to be deprecated in favor of the new
> SNTP Client, ...

The topic of this thread is ntpdate vs. ntpd, and I just wanted to clarify
some statements about ntpdate which are simply wrong.

> ... while this discussion is interesting at face, I see us using
> this information to guide the bahavior of the sntp code and don't expect
> to see any changes to ntpdate (especially since there is no maintainer for
> ntpdate).

>From the discussion here I don't see why any changes should be
required/requested for ntpdate.

> Without thinking about this much, I agree 100% that -u should mean "not
> from port 123".
> I can see cases where one *might* want this behavior for -q but I'm not
> certain it should be forced for -q.
> I wonder quite a bit more why we would want this behavior for -d.
> For either of these last two cases it should be trivial to also supply -u
> if that is what was really desired.

What I've written corresponds to the behaviour of ntpdate as-is, and IMHO
this is very useful.

As I understand this, this is due to the history of ntpdate.

If "ntpdate %host%" was run to set the system time then this worked to set
the initial system time before ntpd was started but did not work if ntpd
already had port 123 open.

This kind of usage may be obsolete after -g has been introduced for ntpd.
BTW, why is the beaviour of ntpd -g not the default? IMHO this is exactly
what users expect from ntpd.

Anyway, ntpdate is still very good to debug NTP problems.

You can run ntpdate -q as a quick test to check the time offset against a
particular server, even if ntpd is running and that server is not in ntpd's
list. If you want to see more details of the packet exchange you can run
ntpdate -d. Both commands can easily be used without interfering with the
running ntpd, and this is mainly because they use a different port to send
the request. 

IMHO programs which do not provide any services should in general use random
ports by default. ntpdate sending requests via port 123 is IMHO an
exception in order to prevent it from unintentionally messing up ntpd. If
sntp can also be run as daemon then maybe it should use port 123 in daemon
mode, but use a random port by default in non-daemon mode.

If ntpd is not running you can use ntpdate with and without -u/-d to see if
a reply from an upstream server is received. This can be helpful to find
out whether a firewall is blocking no ports / all ports / only privileged

The problem with ntpdate is that code which is used in several programs of
the NTP package (ntpd, ntpdate, ntptimeset, ...) has been *copied* from one
program to another instead of putting it into a commonly used source file,
e.g. in libntp. Over the years changes have been applied to the code in
ntpd, but those changes have not made their way into the other programs of
the package.

Recently sntp has been written from scratch. So this a pretty new code base.
However, AFAIK this did not compile e.g. under Windows, and in the mean
time the author/maintainer has disappeared.

Now gsoc-sntp is there, and I don't see how this could be built e.g. under
Windows. What I see is that a number of functions which are available in
ntpd and can be used both under Unix and windows have again been
duplicated/rewritten in gsoc-sntp. So there is one more code base which
needs to be ported and maintained. Great.

BTW, the same basic problem is with the ISC libraries, which also seem to
have been copied e.g. from ISC's bind. Nowadays there a different versions
of the same source code modules both in libisc/ and ports/winnt/libisc,
e.g. interfaceiter.c, isc_strerror.c, and net.c.

IMHO this is also quite error prone. E.g. There are 5 (!) instances of the
isc_interfaceiter_create() function in the code base, 3 below libisc/, and
2 below ports/winnt/libisc/.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list