On 06/07/2014 07:42, 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
detha de...@foad.co.za wrote:
There are some differences between open SMTP relays and networks not
implementing BCP38. TCP versus UDP, and to quote Paul Vixie from
https://queue.acm.org/detail.cfm?id=2578510
] ... but the big reason why SAV isn't the default is: SAV benefits only
] other
On Mon, 07 Jul 2014 07:50:16 +, Rob wrote:
detha de...@foad.co.za wrote:
The biggest problem with NTP is the amplification factor. With a 1:1 or
even 1:1.5 amplification factor, the attacker won't bother, and move to
the next target - SNMP is a good candidate. With a 1:12 or better
On 7/6/2014 2: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 either
I have to agree on some points with these two below. From my experience also,
using KOD usually results in more packet pounding from
bad clients (from what I can only assume is poor coding of custom clients).
The realization is that many clients don't run the standard NTP distribution,
but
Has that *always* been the case? Or has the code be changed over time?
Remember, not everyone is running the latest development (or even stable)
version of NTP...
KOD already sets a timestamp that is the requesters timestamp. See my
previous response. It's better than your idea since it is
On 7/6/2014 12:29 PM, 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 are limited to
On 7/6/2014 7:22 AM, Jan Ceuleers wrote:
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
On Mon, Jul 07, 2014 at 08:35:25AM +0100, David Taylor wrote:
Seconded.
Why remove KOD when it has to be expressly enabled (via
restrict kod and limited)?
I'd rather see a two tier system, where you can enable
the use of KOD beyond the initial rate limit, and a second limit
Danny,
On 07/07/2014 04:00 PM, Danny Mayer wrote:
On 7/6/2014 2: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,
On 07/07/2014 04:10 PM, Danny Mayer wrote:
The experience with blocking has actually being negative and we have
seen traffic actually INCREASE after it is blocked because the client,
not having received a response, tries more often. This has been observed
in the wild.
This might be true for
On 07/07/2014 04:50 PM, Majdi S. Abbas wrote:
On Mon, Jul 07, 2014 at 08:35:25AM +0100, David Taylor wrote:
Seconded.
Why remove KOD when it has to be expressly enabled (via
restrict kod and limited)?
I'd rather see a two tier system, where you can enable
the use of KOD
On 7/7/2014 10:08 AM, Jason Rabel wrote:
Has that *always* been the case? Or has the code be changed over time?
I'm not sure how far back this goes. I can try and find out. I do
remember the discussion I had with Dave Mills on this but that was just
a couple of years ago. I will need to find
On 2014-07-07, Majdi S. Abbas m...@latt.net wrote:
On Mon, Jul 07, 2014 at 08:35:25AM +0100, David Taylor wrote:
Seconded.
Why remove KOD when it has to be expressly enabled (via
restrict kod and limited)?
I'd rather see a two tier system, where you can enable
the use of KOD
Danny Mayer ma...@ntp.org wrote:
On 7/6/2014 2: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
Danny writes:
You haven't read the code. Any client that ignores the KOD flag will
find (if they ever looked) that their clock will be drifting away
further and further from the proper time. When KOD is set the value of
the received and sent timestamps are the same as the initial client
sent
Jason writes:
The realization is that many clients don't run the standard NTP
distribution, but rather some old hacked down / self-coded minimal NTP
/ SNTP version to run on embedded hardware. Likewise many of the
routers don't even use NTPD code with a constantly running daemon, but
rather
Hi there
Jaap Winius wrote:
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 hardware platforms, but those machines have
On 07/07/2014 04:04 PM, Danny Mayer wrote:
I have no particular preference for the immutable time stamp value to
pick. Could be zero, could be some other meaningful value (such as
0xeee4baadeee4baad - twice Eek! Bad!).
KOD already sets a timestamp that is the requesters timestamp. See my
Magnus Danielson mag...@rubidium.dyndns.org wrote:
On 07/07/2014 04:10 PM, Danny Mayer wrote:
The experience with blocking has actually being negative and we have
seen traffic actually INCREASE after it is blocked because the client,
not having received a response, tries more often. This
On Mon, Jul 7, 2014 at 12:39 PM, Rob van der Putten r...@sput.nl wrote:
AFAIK the BBB 232 cape doesn't support DCD, so PPS is not available.
One normally uses a so-called GPIO pin to read PPS on systems that
lack a DCD line or a parallel port. E.g. BeagleBone or Raspberry Pi.
Would it be useful to offer an official minimal implementation
intended for embedded systems so that these people won't feel the need
to code their own? Maybe add minimal NTP support to Busybox?
Actually, Busybox does have a ntp daemon... Where the code comes from I do not
know. I've tried
Rob wrote:
All those problems were not solved by sending KOD
and some of them even not by sending no reply at all.
In fact, some of those broken clients re-try after 1-2 seconds
when you don't reply,
and when you do reply KOD they immediately re-try.
When you reply with correct time
Rob van der Putten wrote:
Hi there
Jaap Winius wrote:
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 hardware
Hi--
On Jul 7, 2014, at 2:03 PM, E-Mail Sent to this address will be added to the
BlackLists Null@BlackList.Anitech-Systems.invalid wrote:
Which product / abused NTP Server / Network / ...
immediately re-tried if they got a KOD?
I've seen that sort of misbehavior from a Lucent / Avaya PBX.
Rob writes:
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
On 2014-07-07 10:00, John Hasler wrote:
Jason writes:
The realization is that many clients don't run the standard NTP
distribution, but rather some old hacked down / self-coded minimal NTP
/ SNTP version to run on embedded hardware. Likewise many of the
routers don't even use NTPD code with a
Jochen Bern wrote:
The straightforward approach to doing so would be to send
out not plain go DIAFs, but messages along the lines
of I'm willing to service your further requests *if*
you label them with this random ID (and behave).
More modern ntpd with the Command Line Option -I,
and /
Jason Rabel wrote:
I think the best thing to do would be to keep it simple
and not reply to a bad client...
It might make a few follow-up queries,
but eventually it would (hopefully) give up.
Broken ones might not {didn't}.
Most of the big abuse issues I read about,
no reply was one of
John Hasler wrote:
Would it be useful to offer an official minimal implementation
intended for embedded systems so that these people won't feel the
need to code their own? Maybe add minimal NTP support to Busybox?
http://wiki.openwrt.org/doc/howto/ntp.client
--
E-Mail Sent to this address
I wrote:
Would it be useful to offer an official minimal implementation
intended for embedded systems so that these people won't feel the need
to code their own? Maybe add minimal NTP support to Busybox?
Brian Inglis writes:
AIUI an updated v4 sntp client will be released to replace ntpdate.
Brian Inglis writes:
On 2014-07-07 10:00, John Hasler wrote:
Jason writes:
The realization is that many clients don't run the standard NTP
distribution, but rather some old hacked down / self-coded minimal NTP
/ SNTP version to run on embedded hardware. Likewise many of the
routers
32 matches
Mail list logo
