NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
The new ntp.conf file format
Please add your comments following the appropriate point of discussion following the existing format (e.g. add your signature at the end of your comment and use
as a separator.) General Comments should go in the section set-up for them. Please add another discussion heading if needed.
Where should we allow each configurable item to be specified?
ntp.conf should be able to specify any NTP-related config-file configurable. Any command-line-only run configuration specifications should be ignored. Most all command line options should be specifiable in the config file. Anything specifiable in ntp.conf should be override-able on the command line.
Allow configuration of (up to) N IPs for a given server/peer.
- Do we really need this for peers?
restrict handling easier?
- Automatic for every server/peer?
- Also see Bug #376
Improved logging/debug facility
- Overriding default settings for locking
ntpd in memory
- Also see Bug #220, Bug #477
There might be something to be said for a command-line override too, but that is getting "busy".
- 24 Jul 2004
Make "exit if things get rough" an option (Wolfgang Rupprecht)
Audio refclock variables
Make hardcoded values (volume, ???) in icom.c configurable here
Also see Bug #291
, Bug #406
and Bug #407
We should allow folks to override the defaults for the setup string, the connect timeout, etc.
I'd like to find a useful library that handled this, and I'd rather not re-implement "expect". My preference would be a BSD-licensed thing, as opposed to a GPL thing.
- 10 Dec 2004
Minpoll,maxpoll driver/user preferences
2005-02-16) Are you saying that if the max and min poll values are initialized in the driver, they overwrite any ntp.conf server options? ... But, doesn't that violate the least astonishment principle? It would be nice to have the driver suggest baseline values and have the user override them if desired...
2005-02-16) I very much second that. I had issues with hard-coded minpoll at the driver-29 (Trimble Palisade) so I had to keep a patch and reapply it for every ntp version upgrade.
2005-02-16) Greg, ...The maxpoll/minpoll values are initialized in newpeer() in ntp_peer.c before the refclock code. It's the same with all associations. You get to set it from the configuration file. While the defaults are inappropriate for the ACTS driver, I'm reluctant to take away the means to change the values. The user can't override the default values in the driver either, unless as you suggested they are fixed...
The values from the command line are set by newpeer() before the refclocks get ahold if it. It would be messy, to say the least, to do this during driver initialization.
More options (fudge) for non-refclocks
I would very much like to see 'fudge time1' being applicable to network reference servers. Like JohnPettitt
, I see a very predictive and stable offsets for network peers due to an asymmetric cable connection.
2005-02-15) It would be nice to expand the fudge to non-refclocks, but this requires rewrite of the configuration code as well as changes in the remote configuration protocol. This in turn requires an asynchronous DNS implementation. Besides providing a broader fudge application, this would provide a really neat automatic pool capability. Nothing wildly difficulat about this, but really down and dirty. Previous broad hints for help in this area haven't raised any hands.
I initially thought this would make more sense on a per-interface basis, but I can see that it might be more useful per-peer.
- 18 Feb 2005
Individual huff'n'puff buffers for each network reference
2004-12-20) You correctly concluded the huffpuff is global, not association specific. Naughty me; I intended to say that in the documentation, but at least the ntpd page doesn't say that. I thought about doing it (only) for the prefer peer. Do you have a preference?
2004-12-20) The current assumption for huffpuff is that all reference clocks are on the other side of a single network connection, and it is the single 'last mile' line that gets into asymmetric congested state. It clearly isn't the case for local reference clock like atom, which have roundtrip delay of 0. More generally, it also isn't so for other peers, each of them may have a differently behaving network leading to it, and sometimes the congested lines are on the remote server side.
The best solution would be for each peer to have its own huffpuff buffer. Apart from costing some memory, I don't think this is a heavy price to pay. If huffpuff could be configurable (at least: enabled/disabled) individually on each 'server' config line, so much the better.
Is this an issue for
or is it an issue for
itself? If the latter, please consider opening an "enhancement" request at http://bugs.ntp.org
- 18 Feb 2005
It's not as simple as you think. In fact, it's not as simple as I thought. The scheme is a maximim a-posteriori (MAP) statisical estimation method. The estimator thinks it has a good measure of the correct value and then collects samples that reinforce that value.
The trick is to reliably estimate the minimum delay over a sufficient time span that insures at least one minimum delay sample is found. From theory, other samples tend to be found at the limbs of what I have called the wedge scattergram, where the limbs are at slopes of +-0.5. On the assumption the samples are on the limbs, just determine the sign and correct for the additional delay. It works equally well for one-sided or two-sided congested paths.
But, this works only if the apex of the wedge can be reliably determined, which is where the MAP method comes in. To do this successfully for different associations would require a separate pseudo-discipline for each association. This would be incredibly intricate, but in principle possible.
-- Dave Mills - 11 Oct 2008