On Sat, 05 Jul 2014 23:37:05 +, Jaap Winius wrote:
Hi folks,
Has anyone here managed to turn a relatively cheap, ARM-based embedded
system with a serial port into a decent stratum 1 NTP server?
Thus far I've always attached my GPS and radio time signal receivers to
much larger x86
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has either no effect at all, or it even has a
On 07/06/2014 08:42 AM, Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way that has no
timekeeping value to the offending
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In real life it has either no effect at all, or it
Magnus Danielson wrote:
Harlan,
On 07/05/2014 11:40 PM, Harlan Stenn wrote:
Folks,
I was chatting with PHK about:
http://support.ntp.org/bin/view/Dev/NtpProtocolResponseMatrix
http://bugs.ntp.org/show_bug.cgi?id=2367
and how we probably want to extend KOD coverage to more than just the
On 07/06/2014 11:23 AM, Rob wrote:
Jan Ceuleers jan.ceule...@computer.org wrote:
I recommend providing motivation for the undesired clients to stop using
the server, by the server sending a regular response indicating that it
is not synchronised or replying in some other way that has no
On 07/06/2014 12:38 PM, Terje Mathisen wrote:
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd.
It does not serve a useful purpose, because precisely the kind of
clients that you want to say goodbye to, do not support it.
In
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
On 07/06/2014 12:38 PM, Terje Mathisen wrote:
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Discussion appreciated.
I think it is best to remove KOD from ntpd. It does not serve a useful
purpose, because precisely the kind of
On Sun, Jul 6, 2014 at 2:25 AM, detha de...@foad.co.za wrote:
Be sure to include some form of
external RTC though.
While sometimes useful a real time clock isn't required on a typical*
S1 server. By the way, some GPS modules have an RTC which (if battery
supported) will produce a reasonable
Detha,
On 07/06/2014 03:23 PM, detha wrote:
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
For cases like that, KOD won't help at all.
All the state table/KOD/filter rules mitigation approaches I have seen so
far are limited to one server. Maybe time to take a look at a
On 2014-07-05 15:40, Harlan Stenn wrote:
Folks,
I was chatting with PHK about:
http://support.ntp.org/bin/view/Dev/NtpProtocolResponseMatrix
http://bugs.ntp.org/show_bug.cgi?id=2367
and how we probably want to extend KOD coverage to more than just the
limited case.
I was assuming folks
Jaap,
You can skim over these past few months on the time-nuts list. There's lots of
threads with discussion on ARM, Beaglebone, Rasberry
Pi, etc... for GPS based NTP servers...
http://www.febo.com/pipermail/time-nuts/2014-March/date.html
On Sun, 06 Jul 2014 16:29:27 +, Magnus Danielson wrote:
Detha,
On 07/06/2014 03:23 PM, detha wrote:
On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
For cases like that, KOD won't help at all.
All the state table/KOD/filter rules mitigation approaches I have seen
so far
detha de...@foad.co.za wrote:
Maybe. For the moment I think it is sufficient if we provide a mechanism
by which offenders gets reported to *some* system. We *could* also provide
a method by which white/black-list can be dynamically set from an external
source, so enough hooks exists, but I do
On Sun, 06 Jul 2014 18:51:16 +, Rob wrote:
detha de...@foad.co.za wrote:
Maybe. For the moment I think it is sufficient if we provide a
mechanism by which offenders gets reported to *some* system. We *could*
also provide a method by which white/black-list can be dynamically set
from an
On -10.01.-28163 20:59, Harlan Stenn wrote:
This gets a bit more complicated when taking into consideration:
- we'll get more traffic from a NAT gateway
- - do we need to be able to configure a threshhold for this case?
Can't say much about KOD as-is, but here's my .02 on the net-behind-NAT
17 matches
Mail list logo
