[ntp:questions] Feature request: logfile timestamp format

[Opty]

Hello,

as it seems that I won't live to see my Bugzilla account, I'm trying this way:

Please add e.g. logfiletimestamp option to ntp.conf (and possibly
command line option -lt string/--logfiletimestamp=string?) to specify
the timestamp format when using alternate log file so one can use e.g.
ISO 8601 format.

Regards,
Opty
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Are mode 6 responses rate controlled?

[Harlan Stenn]

I see ways to improve this, and I'll make improvements in p16.

There will be significant new functionality in this area in the upcoming
4.4 release.

In the meantime, one can use 'restrict noquery' (a feature that has been
available for a very long time) to block mode6 (and mode7, already
disabled by default) from inappropriate sources.  We have been doing
this for many years in the ntp.conf files we use on our servers.

On 5/19/2021 9:18 AM, Brian Utterback wrote:
> We are getting customer inquiries about Mode 6 packets and DDOS packet
> amplification issues. It seems that security audit vendors have started
> checking to see if NTP is allowing mode 6 packets. I am getting some
> pressure to disable them by default. I notice that some vendors have
> indeed done that, but others rate limit mode 6 packets to prevent them
> from being useful in a DDOS. Does the stock NTP distro have such rate
> limiting already built in? If not, is there anything to mitigate the
> problem by default?

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] Are mode 6 responses rate controlled?

[Brian Utterback]

We are getting customer inquiries about Mode 6 packets and DDOS packet 
amplification issues. It seems that security audit vendors have started 
checking to see if NTP is allowing mode 6 packets. I am getting some 
pressure to disable them by default. I notice that some vendors have 
indeed done that, but others rate limit mode 6 packets to prevent them 
from being useful in a DDOS. Does the stock NTP distro have such rate 
limiting already built in? If not, is there anything to mitigate the 
problem by default?

--
--
I haven't lost my mind, it is backed up in the cloud somewhere.

Oracle 
Brian Utterback, Principal Software Engineer
Phone: +16038973049 , Mobile: +16035577683 


https://oracle.zoom.us/s/2728168892 
One Oracle Drive, Nashua, NH 03062

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd on busybox ARM system not keeping time with server

[Terje Mathisen]

Jakob Bohm wrote:

On 2021-05-19 09:55, Terje Mathisen wrote:

Jakob Bohm wrote:

On 2021-05-18 13:56, David Woolley wrote:

On 18/05/2021 12:26, Andreas Schick wrote:

server 127.127.1.0  # local clock (LCL)
fudge  127.127.1.0 stratum 10   # LCL is unsynchronized


Delete these lines.  As described, this system is not suitable as a 
time server, and including these lines on a pure client can actually 
frustrate synchronisation. This fake server is likely to vote 
against the genuine server.




Perhaps the "tos orphan" option is a better way to make ntpd continue
after loss of all time sources.

Maybe some option to force treating the Windows server as stratum 12,
even if it looses outside synch and reports itself as stratum 16.


server  192.168.101.2


This appears to be the machine itself, so it will be voting that's 
its own time is correct.  Delete it.


Windows machines can vary from fair to atrocious as time servers.  A 
workstation running a default configuration of w32time will be at 
the atrocious end.


Fortunately, this is reportedly a server, which means it will keep time
with a somewhat coarse granularity and include a battery backed TOY
(Time Of Year) clock to keep time even across power outages.

W32Time in server mode has a tendency to fluctuate about +/- 10ms from
the time sources.  It is designed to provide an SNTP time source for
Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
KDC.



You should make sure that the ARM starts in the right ball park, by 
either using a file timestamp to record the time at, or close to, 
shutdown, or, as a last resort, setting a fixed time that isn't too 
far from reality.


Perhaps using the sntp program to do initial synchronization to the
server machine (as a better alternative to ntpd -g).


ntpd with iburst is pretty much always better, even more so when you 
have multiple servers configured.




In my experience, ntpd algorithms converge very slowly in the trivial
cases where the initial local clock is not set, and all (or only in the
OPs case) sources agree on the correct time (TrueChimers).


Huh?

With an initial iburst I'm seeing 1-5s convergence.

Terje


--
- 
"almost all programming can be viewed as an exercise in caching"

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd on busybox ARM system not keeping time with server

[David Woolley]

On 19/05/2021 01:57, Jakob Bohm wrote:

Perhaps the "tos orphan" option is a better way to make ntpd continue
after loss of all time sources.


This is a pure client configuration.  There is no need for ntpd to 
continue to serve time after the loss of all sources.  The kernel 
software clock will continue to run, using the last available frequency 
correction supplied by ntpd, without the need for any time island 
mitigation measures.


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd on busybox ARM system not keeping time with server

[Jakob Bohm]

On 2021-05-19 09:55, Terje Mathisen wrote:

Jakob Bohm wrote:

On 2021-05-18 13:56, David Woolley wrote:

On 18/05/2021 12:26, Andreas Schick wrote:

server 127.127.1.0  # local clock (LCL)
fudge  127.127.1.0 stratum 10   # LCL is unsynchronized


Delete these lines.  As described, this system is not suitable as a 
time server, and including these lines on a pure client can actually 
frustrate synchronisation. This fake server is likely to vote against 
the genuine server.




Perhaps the "tos orphan" option is a better way to make ntpd continue
after loss of all time sources.

Maybe some option to force treating the Windows server as stratum 12,
even if it looses outside synch and reports itself as stratum 16.


server  192.168.101.2


This appears to be the machine itself, so it will be voting that's 
its own time is correct.  Delete it.


Windows machines can vary from fair to atrocious as time servers.  A 
workstation running a default configuration of w32time will be at the 
atrocious end.


Fortunately, this is reportedly a server, which means it will keep time
with a somewhat coarse granularity and include a battery backed TOY
(Time Of Year) clock to keep time even across power outages.

W32Time in server mode has a tendency to fluctuate about +/- 10ms from
the time sources.  It is designed to provide an SNTP time source for
Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
KDC.



You should make sure that the ARM starts in the right ball park, by 
either using a file timestamp to record the time at, or close to, 
shutdown, or, as a last resort, setting a fixed time that isn't too 
far from reality.


Perhaps using the sntp program to do initial synchronization to the
server machine (as a better alternative to ntpd -g).


ntpd with iburst is pretty much always better, even more so when you 
have multiple servers configured.




In my experience, ntpd algorithms converge very slowly in the trivial
cases where the initial local clock is not set, and all (or only in the
OPs case) sources agree on the correct time (TrueChimers).



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd on busybox ARM system not keeping time with server

[Miroslav Lichvar]

On 2021-05-18, Andreas Schick  wrote:
> One further idea I had was just modifying some startup scripts (which
> run before ntpd process is started and after the network is up) to
> include some from of a ntpd-run-sync-and-quit or ntpdate call that
> steps the clock at system startup on the ARM device.

Another possibility is to start ntpd normally and wait for it to set the
clock. There is the ntp-wait script for that. On systemd-based
distributions there is a time-sync target which delay start of services
that need accurate clock.

-- 
Miroslav Lichvar

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd on busybox ARM system not keeping time with server

[Terje Mathisen]

Jakob Bohm wrote:

On 2021-05-18 13:56, David Woolley wrote:

On 18/05/2021 12:26, Andreas Schick wrote:

server 127.127.1.0  # local clock (LCL)
fudge  127.127.1.0 stratum 10   # LCL is unsynchronized


Delete these lines.  As described, this system is not suitable as a 
time server, and including these lines on a pure client can actually 
frustrate synchronisation. This fake server is likely to vote against 
the genuine server.




Perhaps the "tos orphan" option is a better way to make ntpd continue
after loss of all time sources.

Maybe some option to force treating the Windows server as stratum 12,
even if it looses outside synch and reports itself as stratum 16.


server  192.168.101.2


This appears to be the machine itself, so it will be voting that's its 
own time is correct.  Delete it.


Windows machines can vary from fair to atrocious as time servers.  A 
workstation running a default configuration of w32time will be at the 
atrocious end.


Fortunately, this is reportedly a server, which means it will keep time
with a somewhat coarse granularity and include a battery backed TOY
(Time Of Year) clock to keep time even across power outages.

W32Time in server mode has a tendency to fluctuate about +/- 10ms from
the time sources.  It is designed to provide an SNTP time source for
Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
KDC.



You should make sure that the ARM starts in the right ball park, by 
either using a file timestamp to record the time at, or close to, 
shutdown, or, as a last resort, setting a fixed time that isn't too 
far from reality.


Perhaps using the sntp program to do initial synchronization to the
server machine (as a better alternative to ntpd -g).


ntpd with iburst is pretty much always better, even more so when you 
have multiple servers configured.


Terje


--
- 
"almost all programming can be viewed as an exercise in caching"

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd on busybox ARM system not keeping time with server

[Harlan Stenn]

On 5/18/2021 5:57 PM, Jakob Bohm wrote:
> On 2021-05-18 13:56, David Woolley wrote:
>> On 18/05/2021 12:26, Andreas Schick wrote:
>>> server 127.127.1.0  # local clock (LCL)
>>> fudge  127.127.1.0 stratum 10   # LCL is unsynchronized
>>
>> Delete these lines.  As described, this system is not suitable as a
>> time server, and including these lines on a pure client can actually
>> frustrate synchronisation. This fake server is likely to vote against
>> the genuine server.

Not if the failover local clock setup configuration is done properly.

> Perhaps the "tos orphan" option is a better way to make ntpd continue
> after loss of all time sources.

Yes, orphan mode is the preferred alternative to local refclocks.

> Maybe some option to force treating the Windows server as stratum 12,
> even if it looses outside synch and reports itself as stratum 16.

I haven't read the messages leading up to this.  If the windows server
is running ntpd it can easily be configured to play an appropriate role
at an appropriate stratum in the collection of local timeservers.  This
could be a local refclock, or better, it could be an appropriate orphan
mode server candidate.

>>> server  192.168.101.2
>>
>> This appears to be the machine itself, so it will be voting that's its
>> own time is correct.  Delete it.
>>
>> Windows machines can vary from fair to atrocious as time servers.  A
>> workstation running a default configuration of w32time will be at the
>> atrocious end.
> 
> Fortunately, this is reportedly a server, which means it will keep time
> with a somewhat coarse granularity and include a battery backed TOY
> (Time Of Year) clock to keep time even across power outages.
> 
> W32Time in server mode has a tendency to fluctuate about +/- 10ms from
> the time sources.  It is designed to provide an SNTP time source for
> Kerberos clients that need to stay within +/- 5 minutes of the Kerberos
> KDC.
> 
>>
>> You should make sure that the ARM starts in the right ball park, by
>> either using a file timestamp to record the time at, or close to,
>> shutdown, or, as a last resort, setting a fixed time that isn't too
>> far from reality.
> 
> Perhaps using the sntp program to do initial synchronization to the
> server machine (as a better alternative to ntpd -g).

People keep saying this, and if the intent is to run ntpd on the box it
should not be needed.  Even around "era" rollovers.  I'd love to clearly
understand what the (alleged?) problem is, because if there is a corner
case where this really is a problem I want to see that case fixed.

> Enjoy
> 
> Jakob

-- 
Harlan Stenn 
http://networktimefoundation.org - be a member!
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions