On Thu, Aug 02, 2012 at 05:57:43AM +, Dave Hart wrote:
On Thu, Aug 2, 2012 at 1:17 AM, Chris Adams wrote:
I'm still seeing leap=01 from 204.235.61.9 (name1.glorb.com), a
stratum-2 server in the US pool (a few of my systems have it in their
list).
That particular system seems to have
Miroslav Lichvar wrote:
On Thu, Aug 02, 2012 at 05:57:43AM +, Dave Hart wrote:
On Thu, Aug 2, 2012 at 1:17 AM, Chris Adams wrote:
I'm still seeing leap=01 from 204.235.61.9 (name1.glorb.com), a
stratum-2 server in the US pool (a few of my systems have it in their
list).
That particular
unruh writes:
On 2012-08-04, Harlan Stenn st...@ntp.org wrote:
unruh writes:
On 2012-08-04, David Woolley david@ex.djwhome.demon.invalid wrote:
Harlan Stenn almost wrote:
The NTP reference implmentation *defines* the spec, and there will
be times when the ...
And it is a reference
In article 501d6636.9050...@gmail.com,
Jeffrey Lerman jeffrey.ler...@gmail.com writes:
On Fri, Aug 03 2012 at 5:42PM, Harlan Stenn st...@ntp.org wrote:
It looks like this recently-filed (and cryptically-named) ntpd bug might
be related to the bogus leap seconds?
On 8/6/2012 8:44 AM, Dick Wesseling wrote:
In article 501d6636.9050...@gmail.com,
Jeffrey Lerman jeffrey.ler...@gmail.com writes:
On Fri, Aug 03 2012 at 5:42PM, Harlan Stenn st...@ntp.org wrote:
It looks like this recently-filed (and cryptically-named) ntpd bug might
be related to
Nathan Stratton Treadway wrote:
date -u; ntpq -c rv 0 leap,stratum,refid name1.glorb.com
The command above doesn't report the version of the NTP daemon running on
that system.
date -u; /usr/sbin/ntpq -p -c rv name1.glorb.com
So 5. Aug 09:52:26 UTC 2012
remote refidst t when poll
E-Mail Sent to this address will be added to the BlackLists wrote:
Martin Burnicki wrote:
clients to independently set LI=00 during, say the first
half of the month, and to ignore the LI value from
servers during that time.
I think you would have to be more exact than that.
LI is used
Jeffrey Lerman wrote:
The unfortunate combination of the bogus leap second and the
newly-discovered (on July 1) Linux kernel bug related to leap-second
handling means that bogus leap seconds have a much bigger-than-normal
impact.
I think a main problem here is that there are many software
On 2012-08-04, Harlan Stenn st...@ntp.org wrote:
unruh writes:
On 2012-08-04, David Woolley david@ex.djwhome.demon.invalid wrote:
Harlan Stenn almost wrote:
The NTP reference implmentation *defines* the spec, and there will
be times when the ...
And it is a reference implimentation, not
Harlan Stenn wrote:
Oh, my mistake: I quote RFC5905 below, which is for NTPv4, which is
technically in _draft_ status - though it does seem pretty far along and
I believe current ntpd adheres to NTPv4, not v3.
The NTP code *defines* the spec, and there will be times when the
I think you
David Woolley writes:
Harlan Stenn wrote:
Oh, my mistake: I quote RFC5905 below, which is for NTPv4, which is
technically in _draft_ status - though it does seem pretty far along and
I believe current ntpd adheres to NTPv4, not v3.
The NTP code *defines* the spec, and there will be
On 2012-08-04, David Woolley david@ex.djwhome.demon.invalid wrote:
Harlan Stenn wrote:
Oh, my mistake: I quote RFC5905 below, which is for NTPv4, which is
technically in _draft_ status - though it does seem pretty far along and
I believe current ntpd adheres to NTPv4, not v3.
The NTP
On Fri, Aug 03 2012 at 5:42PM, Harlan Stenn st...@ntp.org wrote:
Jeff wrote:
Is the leap bit supposed to be cleared by a client if it gets LI=00
from a server? Or is the bit only *set* based on information from a
server, and cleared only upon application of the leap second? If the
latter is
The relationship between a protocol, the RFC that defines it and the
reference implementation (if there is one) is often not straight forward.
The early RFC almost all documented existing programs and the protocols
that they implemented. This tradition has continued to this day because
a
unruh wrote:
I think that the reference implimentation impliments a specific rfc. Ie,
the rfc comes first.
My understanding is the reverse. My understanding is that the RFC
system requires a reference implementation, to prove that the
specification is implementable, before the
On 8/4/2012 12:28 PM, unruh wrote:
On 2012-08-04, David Woolley david@ex.djwhome.demon.invalid wrote:
Harlan Stenn wrote:
Oh, my mistake: I quote RFC5905 below, which is for NTPv4, which is
technically in _draft_ status - though it does seem pretty far along and
I believe current ntpd adheres
unruh writes:
On 2012-08-04, David Woolley david@ex.djwhome.demon.invalid wrote:
Harlan Stenn almost wrote:
The NTP reference implmentation *defines* the spec, and there will
be times when the ...
And it is a reference implimentation, not the definition. Ie, it is an
implimentation that is
On Thu, Aug 02, 2012 at 05:57:43 +, Dave Hart wrote:
On Thu, Aug 2, 2012 at 1:17 AM, Chris Adams wrote:
I'm still seeing leap=01 from 204.235.61.9 (name1.glorb.com), a
stratum-2 server in the US pool (a few of my systems have it in their
list).
That particular system seems to have
steven Sommars wrote:
One root cause involves a group of stratum one's peering each other. A
leap indicator can continue to circulate until the peering changes, or the
entire group is simultaneously reinitialized. This affects multiple
commercial server brands.
Is this a problem with
Jeffrey Lerman wrote:
Assuming that the current ntpd design spec is that:
a) Leap second flags can be cleared by EITHER the passage of the
actual leap second, OR the receipt (at any time) of a LI=0 from the
current upstream server
b) Leap second flags can be set by receipt (at any time)
Martin Burnicki wrote:
clients to independently set LI=00 during, say the first
half of the month, and to ignore the LI value from
servers during that time.
I think you would have to be more exact than that.
LI is used for more than one thing.
Oh, my mistake: I quote RFC5905 below, which is for NTPv4, which is
technically in _draft_ status - though it does seem pretty far along and
I believe current ntpd adheres to NTPv4, not v3.
For what it's worth the most recently approved protocol is, technically,
NTPv3, documented in RFC1305
Jeff wrote:
Oh, my mistake: I quote RFC5905 below, which is for NTPv4, which is
technically in _draft_ status - though it does seem pretty far along and
I believe current ntpd adheres to NTPv4, not v3.
The NTP code *defines* the spec, and there will be times when the
current spec and the
Fair enough. Though with a definition like that, it's formally
impossible to distinguish bugs from intentional behavior (features).
Anyway, I'm guessing you know the design intent, as well as the relevant
implementations, pertaining to the question I posed further down in that
email, namely:
Jeffrey Lerman wrote:
Can anyone demonstrate whether ntpd clears the bit if it
is set but an upstream server is configured and sends an
LI=00 update?
See: ntp_proto.c ntp_timer.c ?
... and platform dependent stuff ?
nt_clockstuff.c e.g. Disarm leap second only if the leap second is not
Jeff wrote:
Is the leap bit supposed to be cleared by a client if it gets LI=00
from a server? Or is the bit only *set* based on information from a
server, and cleared only upon application of the leap second? If the
latter is the current implementation, it might well explain the bogus
leap
On Thu, Aug 2, 2012 at 1:17 AM, Chris Adams wrote:
I'm still seeing leap=01 from 204.235.61.9 (name1.glorb.com), a
stratum-2 server in the US pool (a few of my systems have it in their
list).
That particular system seems to have corrected its leap indication,
but plenty of other pool
E-Mail Sent to this address will be added to the BlackLists wrote:
Martin Burnicki wrote:
It turned out this happened with some older versions of
ntpd when the customers had installed e.g. 3 or 4 servers
for redundancy, and each NTP server had the other ones
configured as upstream server
Hi Steven,
Thanks for the research - very interesting. Which stratum-1 servers are
still advertising LI=01? Is it possible to contact their administrators
to learn why they might be erroneously advertising? Can you see if those
servers have anything in common?
How are the leap-second
One root cause involves a group of stratum one's peering each other. A
leap indicator can continue to circulate until the peering changes, or the
entire group is simultaneously reinitialized. This affects multiple
commercial server brands.
Is this a problem with some/all versions of ntpd?
Jeffrey Lerman wrote:
How are the leap-second flags meant to be cleared after a leap second?
Is it supposed to be automatic? Is there a bug in some code (ntpd or
elsewhere) that is failing to clear the flag in (some versions of) ntp
server software?
I've just run some tests. On a test
On 8/1/2012 11:54 AM, Rob wrote:
steven Sommars stevesommars...@gmail.com wrote:
I've seen no evidence of a denial of service attack, bugs are more likely.
Several stratum one servers have been advertising LI=1 continuously for
the past month. Others alternate between LI=0 and LI=1.
Most
Richard B. Gilbert wrote: Does ANYONE use a stratum 10 server?
Sure all the way up to S 15.
I rarely see them getting past S 4 in practice,
except for when fudged / orphaned to a higher stratum.
If so, how good is the time?
That would mostly depend on the dispersion
of every server
jclerm...@gmail.com wrote:
Can someone explain why this was done?
(Shrug)
If they were pool clocks, anything is possible,
occasionally the date appears to change on some of them.
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
On 01/08/12 04:40, jclerm...@gmail.com wrote:
Yes, this affected us. Can someone explain why this was done? Was
it designed to be a test of some kind? The Linux leap second kernel
bug that was discovered a month ago was only patched on July 17; that
patched kernel has presumably not made it
On 01/08/12 10:28, Marco Marongiu wrote:
I tried to collect some information around the globe, but with scarce/no
feedback. I am *suspecting* that this could be a rather imaginative
attempt to DOS worldwide.
Anyway, a colleague of mine is now hunting down some upstreams that
faked the leap
On 01/08/12 14:58, Marco Marongiu wrote:
Question now is: assuming those servers were running ntpd, was such a
bug reported at some point?
Plus, another question. If one uses the leapfile, are spurious leap
second notifications like this one discarded?
From the docs at
I've seen no evidence of a denial of service attack, bugs are more likely.
Several stratum one servers have been advertising LI=1 continuously for
the past month. Others alternate between LI=0 and LI=1.
Most servers claim to run ntpd.
There are over 10 stratum one's that advertise LI=1 as of
Hi, I tried to find some info because there was other leap second, but I didn't
find anything about this issue. Does somebody has some info what happened or
know if it was a DOS atack or if it was a problem of the ntp services (I'm
using the ntp Dabian pools)?
Thanks in advance
steven Sommars stevesommars...@gmail.com wrote:
I've seen no evidence of a denial of service attack, bugs are more likely.
Several stratum one servers have been advertising LI=1 continuously for
the past month. Others alternate between LI=0 and LI=1.
Most servers claim to run ntpd.
There
The main standard says a leap second is allowed in any month. That's what
the reference ntpd does.
See ITU-R, TF460, STANDARD-FREQUENCY AND TIME-SIGNAL EMISSIONS.
This link may work:
http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf
On the other hand Bulletin C
All,
I found that: http://www.greyware.com/kb/kb2012.717.asp
One of my internal NTP servers has the leap flag set to 01. The fake leap
second issue was produced in the servers where this NTP server is the time
source preferred, so I guess that it was my problem.
In order to check the leap
There are over 10 stratum one's that advertise LI=1 as of Wed Aug 1
14:18:51 UTC 2012. Unless this changes another false leap second could
occur on August 31, 2012
Steven, can you point me to one of those servers? The ones that I've checked
all seem to have LI=0.
Thanks!
P.
On Wednesday, August 1, 2012 7:33:25 AM UTC-7, steven Sommars wrote:
I've seen no evidence of a denial of service attack, bugs are more likely..
Several stratum one servers have been advertising LI=1 continuously for
the past month. Others alternate between LI=0 and LI=1.
Most
Hi all,
Marco Marongiu wrote:
Hi all
This is just to warn you that there are now some NTP servers around the
globe spreading a leap second announcement for tomorrow 00:00:00 UTC
(so, basically, in a few hours now).
If you didn't take action before the leapocalypse last month, you better
Martin Burnicki wrote:
It turned out this happened with some older versions of
ntpd when the customers had installed e.g. 3 or 4 servers
for redundancy, and each NTP server had the other ones
configured as upstream server (personally I know this is
not a good configuration, but they did
Once upon a time, Marco Marongiu brontoli...@gmail.com said:
This is just to warn you that there are now some NTP servers around the
globe spreading a leap second announcement for tomorrow 00:00:00 UTC
(so, basically, in a few hours now).
I'm still seeing leap=01 from 204.235.61.9
Hi all
This is just to warn you that there are now some NTP servers around the
globe spreading a leap second announcement for tomorrow 00:00:00 UTC
(so, basically, in a few hours now).
If you didn't take action before the leapocalypse last month, you better
hurry now.
Ciao
-- bronto
On Tuesday, July 31, 2012 1:23:35 PM UTC-7, Marco Marongiu wrote:
Hi all
This is just to warn you that there are now some NTP servers around the
globe spreading a leap second announcement for tomorrow 00:00:00 UTC
(so, basically, in a few hours now).
If you didn't take action
49 matches
Mail list logo
