On Feb 9, 3:07 pm, jlevine wrote:
> In the last few days I have seen an increasing number of systems that
> are requesting the time in NTP format several times per second. This
> poll interval is far in excess of the usual best practices. Since
> there are a number of such systems, it is possible
>Properly functioning ethernet has minimum packet lengths that guarantee
>that it one receiver sees a collision, all of them see the collision.
>Therefore collisions should never result in duplicate packets at the
>application layer.
There is a "should" in there that assumes everything is work
Danny, Judah,
There might be some misunderstanding here. The current KoD scheme is
part of a larger strategy for rate managment. The input packet rate and
rsponse rate including KoD are components in an overall strategy. The
input rate is monitored and packets dropped to achieve an overall
fa
jlevine wrote:
> Thanks to all of you who responded to my initial post regarding very
> rapid
> polling. I have fixed this particular instance with some cooperation
> from the
> ISP. However, the generic problem remains and is likely to re-appear.
> I don't know of a good general solution to this p
jlevine wrote:
>2. Sending any reply at all doubles the network traffic and makes
> an
> attack more effective. Therefore, all of the NIST servers log the
> event and
> the source ip but do not respond. I think it is not appropriate for a
> national
> timing laboratory to knowingly send the wr
On February 25, 2009 13:12, in comp.protocols.time.ntp, Rob
(nom...@example.com) wrote:
> jlevine wrote:
>>2. Sending any reply at all doubles the network traffic and makes
>> an
>> attack more effective. Therefore, all of the NIST servers log the
>> event and
>> the source ip but do not resp
On Feb 23, 9:07 am, jlevine wrote:
>
> 2. Sending any reply at all doubles the network traffic and makes
> an
> attack more effective. Therefore, all of the NIST servers log the
> event and
> the source ip but do not respond. I think it is not appropriate for a
> national
> timing laboratory to
jlevine writes:
>Thanks to all of you who responded to my initial post regarding very
>rapid
>polling. I have fixed this particular instance with some cooperation
>from the
>ISP. However, the generic problem remains and is likely to re-appear.
Could you tell us what the problem was? Was it an at
Thanks to all of you who responded to my initial post regarding very
rapid
polling. I have fixed this particular instance with some cooperation
from the
ISP. However, the generic problem remains and is likely to re-appear.
I don't know of a good general solution to this problem because:
1. the
David Woolley wrote:
> gary.limanap...@elisys.co.uk wrote:
>
>>
>> We are running W32Time on all machines including the servers. The
>> server itself obtains its own time independantly via a hardware clock.
>> This is used to update the CMOS clock from which W32Time then serves
>> out to the Clie
Terje Mathisen wrote:
> David Woolley wrote:
>> Danny Mayer wrote:
>>> David Woolley wrote:
Danny Mayer wrote:
> There is no way to mark an NTP packet as invalid but then why would
> you
There are several ways of marking a packet as effectively invalid.
The real probl
David Woolley wrote:
> Danny Mayer wrote:
>> David Woolley wrote:
>>> Danny Mayer wrote:
>>>
There is no way to mark an NTP packet as invalid but then why would you
>>> There are several ways of marking a packet as effectively invalid.
>>> The real problem is that there is a lot of software
David Woolley wrote:
> Danny Mayer wrote:
>> David Woolley wrote:
>>> Danny Mayer wrote:
>>>
There is no way to mark an NTP packet as invalid but then why would you
>>> There are several ways of marking a packet as effectively invalid. The
>>> real problem is that there is a lot of software
Danny Mayer wrote:
> David Woolley wrote:
>> Danny Mayer wrote:
>>
>>> There is no way to mark an NTP packet as invalid but then why would you
>> There are several ways of marking a packet as effectively invalid. The
>> real problem is that there is a lot of software out there (including
>> w32t
David Woolley wrote:
> Danny Mayer wrote:
>
>> There is no way to mark an NTP packet as invalid but then why would you
>
> There are several ways of marking a packet as effectively invalid. The
> real problem is that there is a lot of software out there (including
> w32time) that will accept p
David Woolley writes:
>Uwe Klein wrote:
>> The hardware does automatic resend on collision using an
>> exponential+random backoff algorithm.
>Properly functioning ethernet has minimum packet lengths that guarantee
>that it one receiver sees a collision, all of them see the collision.
>Therefo
David Woolley wrote:
> Uwe Klein wrote:
>
>> The hardware does automatic resend on collision using an
>> exponential+random backoff algorithm.
>>
> Properly functioning ethernet has minimum packet lengths that guarantee
> that it one receiver sees a collision, all of them see the collision.
> Th
Danny Mayer wrote:
>
> There is no way to mark an NTP packet as invalid but then why would you
There are several ways of marking a packet as effectively invalid. The
real problem is that there is a lot of software out there (including
w32time) that will accept packets that the protocol says t
Uwe Klein wrote:
> The hardware does automatic resend on collision using an
> exponential+random backoff algorithm.
>
Properly functioning ethernet has minimum packet lengths that guarantee
that it one receiver sees a collision, all of them see the collision.
Therefore collisions should never r
gary.limanap...@elisys.co.uk wrote:
>
> How do I upload a JPEG of the CommView Log File showing the rapid
Please use PNG; JPEG always produces degraded images of text in
screenshots, and for sensibly designed screens also produces bigger
files than PNG or GIF.
Better, use something like tcpdu
gary.limanap...@elisys.co.uk wrote:
>
> We are running W32Time on all machines including the servers. The
> server itself obtains its own time independantly via a hardware clock.
> This is used to update the CMOS clock from which W32Time then serves
> out to the Clients. I will take up your sugge
Uwe Klein wrote:
> Richard B. Gilbert wrote:
>> Uwe Klein wrote:
>>
>>> gary.limanap...@elisys.co.uk wrote:
>>>
On Feb 15, 9:15 am, Uwe Klein
wrote:
> gary.limanap...@elisys.co.uk wrote:
>
>> Just joining this discussion as we have noticed NTP request from our
>> Aut
On Feb 15, 4:20 am, gary.limanap...@elisys.co.uk wrote:
>
> How do I upload a JPEG of the CommView Log File showing the rapid
> polling to this discussion?
tinypic.com is your friend.
HTH
___
questions mailing list
questions@lists.ntp.org
https://lists
gary.limanap...@elisys.co.uk wrote:
> On Feb 15, 9:15 am, Uwe Klein
> wrote:
>> gary.limanap...@elisys.co.uk wrote:
>>> Just joining this discussion as we have noticed NTP request from our
>>> Authorised Server every 300ms on our LAN. They occur only between the
>>> Time Server and the WiFi Tablet
Richard B. Gilbert wrote:
> Uwe Klein wrote:
>
>> gary.limanap...@elisys.co.uk wrote:
>>
>>> On Feb 15, 9:15 am, Uwe Klein
>>> wrote:
>>>
gary.limanap...@elisys.co.uk wrote:
> Just joining this discussion as we have noticed NTP request from our
> Authorised Server every 300ms on
gary.limanap...@elisys.co.uk wrote:
> On Feb 15, 3:06 am, Unruh wrote:
>> Steve Kostecke writes:
>>> On 2009-02-14, Unruh wrote:
gary.limanap...@elisys.co.uk writes:
> The only way we can stop it is to disable W32Time process on the
> Tablets, but this then leaves them unsynchronise
Uwe Klein wrote:
> gary.limanap...@elisys.co.uk wrote:
>> On Feb 15, 9:15 am, Uwe Klein
>> wrote:
>>
>>> gary.limanap...@elisys.co.uk wrote:
>>>
Just joining this discussion as we have noticed NTP request from our
Authorised Server every 300ms on our LAN. They occur only between the
Unruh wrote:
> Steve Kostecke writes:
>
>> On 2009-02-14, Unruh wrote:
>
>>> gary.limanap...@elisys.co.uk writes:
>>>
The only way we can stop it is to disable W32Time process on the
Tablets, but this then leaves them unsynchronised. Still searching for
a solution?
>>> So this de
On 2009-02-15, gary.limanap...@elisys.co.uk wrote:
> How do I upload a JPEG of the CommView Log File showing the rapid
> polling to this discussion.
Place the image on a web-server somewhere and tell us the URL.
If you are registered at support.ntp.org you may attach the image to
your UserTopic.
David Mills wrote:
> Danny,
>
> For clarification, the late code returns the KoD with client timestamps
> unchanged. No server timestamps are revealed.
>
> Dave
Right. We had discussed it. In fact any client ignoring the fact that
they are KOD packets will find that their clocks drift further a
Danny,
For clarification, the late code returns the KoD with client timestamps
unchanged. No server timestamps are revealed.
Dave
Danny Mayer wrote:
>Eric wrote:
>
>
>>On Tue, 10 Feb 2009 23:38:07 -0500, "Richard B. Gilbert"
>> wrote for the entire planet to see:
>>
>>
>>
>>>Danny Mayer
>Would it matter if the packet colided? NTP is using UDP and I can't
>see from the packet analyser that it is expects a response back. When
>it does work with a known good machine there is no acknowledgement of
>the packet being sent. Do you think that there another level of
>operation in the netw
gary.limanap...@elisys.co.uk wrote:
> On Feb 15, 9:15 am, Uwe Klein
> wrote:
>
>>gary.limanap...@elisys.co.uk wrote:
>>
>>>Just joining this discussion as we have noticed NTP request from our
>>>Authorised Server every 300ms on our LAN. They occur only between the
>>>Time Server and the WiFi Tabl
On Feb 15, 10:20 am, gary.limanap...@elisys.co.uk wrote:
> On Feb 15, 9:15 am, Uwe Klein
> wrote:
>
> > gary.limanap...@elisys.co.uk wrote:
> > > Just joining this discussion as we have noticed NTP request from our
> > > Authorised Server every 300ms on our LAN. They occur only between the
> > > T
On Feb 15, 9:15 am, Uwe Klein
wrote:
> gary.limanap...@elisys.co.uk wrote:
> > Just joining this discussion as we have noticed NTP request from our
> > Authorised Server every 300ms on our LAN. They occur only between the
> > Time Server and the WiFi Tablet during a socket connection while there
>
On Feb 15, 9:15 am, Uwe Klein
wrote:
> gary.limanap...@elisys.co.uk wrote:
> > Just joining this discussion as we have noticed NTP request from our
> > Authorised Server every 300ms on our LAN. They occur only between the
> > Time Server and the WiFi Tablet during a socket connection while there
>
On Feb 15, 3:06 am, Unruh wrote:
> Steve Kostecke writes:
> >On 2009-02-14, Unruh wrote:
> >> gary.limanap...@elisys.co.uk writes:
>
> >>>The only way we can stop it is to disable W32Time process on the
> >>>Tablets, but this then leaves them unsynchronised. Still searching for
> >>>a solution?
gary.limanap...@elisys.co.uk wrote:
> Just joining this discussion as we have noticed NTP request from our
> Authorised Server every 300ms on our LAN. They occur only between the
> Time Server and the WiFi Tablet during a socket connection while there
> is a low signal strength. The Tablet sends i
Eric wrote:
> On Tue, 10 Feb 2009 23:38:07 -0500, "Richard B. Gilbert"
> wrote for the entire planet to see:
>
>> Danny Mayer wrote:
>>> Eric wrote:
The only mitigation I can think of here is for NTP to not respond to
excessive rate queries at all, or very infrequently, after the KOD.
>
On 2009-02-14, Unruh wrote:
> gary.limanap...@elisys.co.uk writes:
>
>>The only way we can stop it is to disable W32Time process on the
>>Tablets, but this then leaves them unsynchronised. Still searching for
>>a solution?
>
> So this definitely sounds like a bug of some kind in the Windows
> ser
Steve Kostecke writes:
>On 2009-02-14, Unruh wrote:
>> gary.limanap...@elisys.co.uk writes:
>>
>>>The only way we can stop it is to disable W32Time process on the
>>>Tablets, but this then leaves them unsynchronised. Still searching for
>>>a solution?
>>
>> So this definitely sounds like a bug
gary.limanap...@elisys.co.uk writes:
>Hi,
>Just joining this discussion as we have noticed NTP request from our
>Authorised Server every 300ms on our LAN. They occur only between the
>Time Server and the WiFi Tablet during a socket connection while there
>is a low signal strength. The Tablet send
On Feb 11, 11:52 pm, Unruh wrote:
> "Richard B. Gilbert" writes:
>
>
>
>
>
> >Unruh wrote:
> >> "Richard B. Gilbert" writes:
>
> >>> Unruh wrote:
> "Richard B. Gilbert" writes:
>
> > jlevine wrote:
> >> In the last few days I have seen an increasing number of systems that
> >>
ma...@ntp.org (Danny Mayer) writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> Unruh wrote:
"Richard B. Gilbert" writes:
> jlevine wrote:
>> In the last few days I have seen an increasing number of systems that
>> are requesting the time in NTP format several tim
"Richard B. Gilbert" writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> Unruh wrote:
"Richard B. Gilbert" writes:
> jlevine wrote:
>> In the last few days I have seen an increasing number of systems that
>> are requesting the time in NTP format several times per
On Tue, 10 Feb 2009 23:38:07 -0500, "Richard B. Gilbert"
wrote for the entire planet to see:
>Danny Mayer wrote:
>> Eric wrote:
>
>>> The only mitigation I can think of here is for NTP to not respond to
>>> excessive rate queries at all, or very infrequently, after the KOD.
>>>
>>> - Eric
>>
>>
Judah,
Recent versions of NTP have very serious rate controls that prevent
clients from exceeding specified burst rate and average headway
constraints, even if improperly configured. Client packets that violate
these constraints are discarded and, if so configured, the server will
toss back a
Danny Mayer wrote:
> Eric wrote:
>> On Mon, 9 Feb 2009 14:07:26 -0800 (PST), jlevine
>> wrote for the entire planet to see:
>>
>>> In the last few days I have seen an increasing number of systems that
>>> are requesting the time in NTP format several times per second.
>> Have you considered the p
Unruh wrote:
> "Richard B. Gilbert" writes:
>
>> Unruh wrote:
>>> "Richard B. Gilbert" writes:
>>>
jlevine wrote:
> In the last few days I have seen an increasing number of systems that
> are requesting the time in NTP format several times per second. This
> poll interval is far
Unruh wrote:
> "Richard B. Gilbert" writes:
>
>> Unruh wrote:
>>> "Richard B. Gilbert" writes:
>>>
jlevine wrote:
> In the last few days I have seen an increasing number of systems that
> are requesting the time in NTP format several times per second. This
> poll interval is far
Eric wrote:
> On Mon, 9 Feb 2009 14:07:26 -0800 (PST), jlevine
> wrote for the entire planet to see:
>
>> In the last few days I have seen an increasing number of systems that
>> are requesting the time in NTP format several times per second.
>
> Have you considered the possibility that they ar
Richard B. Gilbert wrote:
> Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> jlevine wrote:
In the last few days I have seen an increasing number of systems that
are requesting the time in NTP format several times per second. This
poll interval is far in excess of the usual best
"Richard B. Gilbert" writes:
>Unruh wrote:
>> "Richard B. Gilbert" writes:
>>
>>> jlevine wrote:
In the last few days I have seen an increasing number of systems that
are requesting the time in NTP format several times per second. This
poll interval is far in excess of the usual
On Mon, 9 Feb 2009 14:07:26 -0800 (PST), jlevine
wrote for the entire planet to see:
>In the last few days I have seen an increasing number of systems that
>are requesting the time in NTP format several times per second.
Have you considered the possibility that they are spoofed queries from a
b
On Feb 9, 8:26 pm, ma...@ntp.isc.org (Danny Mayer) wrote:
> jlevine wrote:
> > In the last few days I have seen an increasing number of systems that
> > are requesting the time in NTP format several times per second. This
> > poll interval is far in excess of the usual best practices. Since
> > the
Unruh wrote:
> "Richard B. Gilbert" writes:
>
>> jlevine wrote:
>>> In the last few days I have seen an increasing number of systems that
>>> are requesting the time in NTP format several times per second. This
>>> poll interval is far in excess of the usual best practices. Since
>>> there are a
"Richard B. Gilbert" writes:
>jlevine wrote:
>> In the last few days I have seen an increasing number of systems that
>> are requesting the time in NTP format several times per second. This
>> poll interval is far in excess of the usual best practices. Since
>> there are a number of such systems,
jlevine wrote:
> In the last few days I have seen an increasing number of systems that
> are requesting the time in NTP format several times per second. This
> poll interval is far in excess of the usual best practices. Since
> there are a number of such systems, it is possible that this problem
>
jlevine wrote:
> In the last few days I have seen an increasing number of systems that
> are requesting the time in NTP format several times per second. This
> poll interval is far in excess of the usual best practices. Since
> there are a number of such systems, it is possible that this problem
>
In the last few days I have seen an increasing number of systems that
are requesting the time in NTP format several times per second. This
poll interval is far in excess of the usual best practices. Since
there are a number of such systems, it is possible that this problem
is a result of a new vers
60 matches
Mail list logo
