[lug] What's up with the NIST time servers (fwd)

[J. Wayde Allen]

---------- Forwarded message ----------
Date: Wed, 9 May 2001 14:46:46 -0600 (MDT)
From: Judah Levine <jlevine at clock.bldrdoc.gov>
To: wallen at its.bldrdoc.gov
Cc: jlevine at clock.bldrdoc.gov
Subject: Re: [lug] What's up with the NIST time servers (fwd)

  I have looked at all of the posted comments. Although many of the 
comments do not mention a particular program, all of the folks who
do so are having problems using rdate. My Linux documentation does not
describe how Linux rdate works, but the "standard" UNIX documentation does.
Based on this documentation (which may not apply to Linux, but is the
best that I can do at the moment), there are two potential problems
with using rdate:

	1.  The rdate program sends "broadcast" packets. These are often
	regarded as "unfriendly" by many routers and gateways, and they
	are often not allowed to pass through as a result. My guess is
	that the NIST gateway is now blocking these type of packets, and
	that is why rdate has stopped working on that network while 
	continuing to work on other networks. Many firewalls and proxy
	servers now block these kind of packets because they have been
	used in various denial-of-service attacks, and because allowing
	them to get through can put lots of traffic on an internal network
	that may not belong there.

	2. The rdate program communicates with a server through udp/ip
	port 37 (the "time" protocol) and expects and answer that 
	conforms to that protocol (RFC 866 & 868). Although our servers
	support this protocol, I strongly discourage using it. In
	the first place, it has no error checking or status reporting,
	and many client programs respond to errors by setting the client
	to a time in 2036 or by not doing anything at all. In the second 
	place, it has no provision for measuring the network delay,  which 
	can be a signficant factor.

   Although the issues in paragraph 2 are potential problems, the 
failures that you report are most likely due to something like the
reason outlined in paragraph 1. I would suggest that the first step
is to verify that rdate uses broadcast packets by default and to see
if this can be turned off in some way. That may solve the problem.

   An alternative is to use some of the simple programs that are on
our servers or that are distributed by others. For example, you might
consider the Simple Network Time Protocol (SNTP), which is distributed
by the University of Delaware and which also comes as part of many
Linux distributions. This is a more robust protocol in that it measures
the network delay and provides error checking.  You also use anonymous
ftp directory /pub/daytime on any of our servers (except for time-a.timefreq).
There are a number of example programs there that should work on Linux
systems as is. For example, copy tcp_time_client.c, sw.c and the Makefile
and use these files to build nistime. Look at the comments in the source
code to customize this program as you wish. This will use tcp/ip port 13
to communicate with our servers. The reply contains some additional
information, including advance notice of leap seconds and daylight
saving time transitions. (Of course, you can ignore this stuff if you
wish.) You can also copy file udp_time_client.c, which will build
a program that communicates with our servers using udp/ip port 37
(as does rdate), but which does not use broadcast packets and should
therefore pass through most gateways with no problems.

  Finally, if there are problems with programs OTHER than rdate, please
give me as much information as you can about the program, the error
message (if any), etc. If the program is something that is not in
one of the common things, it would help if you could tell me how it 
communicates with our servers and what sort of reply it expects.


Judah Levine
Time and Frequency Division
NIST Boulder