[ntp:hackers] Recent

David L. Mills mills at udel.edu
Thu Feb 5 09:54:33 PST 2004


Guys,

While making flow charts for some of the algorithms I discovered little
warts now fixed in a few places. Most of this was in defense of busy
servers being ganged up by evil clients.

1. When a server is lost, the client ramps up the poll interval. If
burst mode is enabled, the client does not send a burst, only a single
poll. This in response to the rather large number of KoD occasions
involving burst mode seen at the USNO and NIST time servers.

2. When a definitive crypto error is found, the client stops sending.
This is like the KoD response and Autokey crypto response and applies
now also to symmetric key errors. This is in response to the
surprisingly large number of authentication errors at the USNO and NIST
time servers.

3. A number of little packet counter errors were found and fixed. Some
of these were over ten years old. This applies primarily to ntpdc
statistics; however, the ntpdc program itself reports some statistics in
error.

4. The flow chart for the transmit routine was rebuilt; it had become
too twisty. The new flow is smaller, more straighforward and robust.
 
5. The packet processing code was vetted and small changes made to fix
security potholes, mainly in the area where the bad guy hammers
intentionally bogus packets trying to deny service to the good guy.

By mistrake I edited the ntp_proto.c and ntp_refclock.c file in
ntp-4.2.0 rather than ntp-dev. Sorry about that; the original files
should be restored from SCCS. However, the files I abused really are
old. There are a surprising number of little nits I found long since
fixed. I watch this code very closely and go over it again and again
looking for consistency and robustness and repairing little nits
accumulated over fifteen years. I have to tell you it's pretty
discouraging to do that and find the repairs don't get widely
distributed for many months to a year.

I have been trying to disentangle the spiderwebs of dependencies in the
code. There are three areas where past attempts have failed miserably,
the I/O code, the systime.c code and the audio.c code, not to mention
wads and wads of spiders in the include files. I have tasked students on
occasion to spend some time to make some order in these places, but all
have refused flat out to do that. I have confidence in the I/O code
because Danny actively watches it and fixes what breaks. I can't even do
it myself for the other areas. This is not necessarily a criticism of
the current Corps, as it has been getting spiders for fifteen years.

The recent audio.c issue is very painful, as I wrote the original code.
I tried to fix something the other day and was astonished at the briar
patch it has become. There is no excuse for that; good programming
practice would not have allowed the forest of ifdefs for various systems
to flourish. Better separate routines for each architecture.

The real problem is some jaywalker installs support for a j-random new
system as a ifdef spiderweb in the existing code. Years later some poor
clod like me tries to make sense out of it and fails miserably,
especially as there are very few comments about why the web is there in
the first place. I'm sure you noticed the vigor on my part in comment
flourish. When you watch code like this for fifteen years, you get
mighty squirrelly, even in your own code.

Dave



More information about the hackers mailing list