|
Info from https://www.zdnet.com/article/thanks-to-a-nasty-gpsd-bug-real-life-time-travel-trouble-arrives-this-weekend/
WSJT users typically utilize frequent time synchronization via upstream time servers on the web. According to this article, "a nasty bug's been uncovered in GPSD that's going to pop up on October 24, 2021. If left unpatched, it's going to switch your time to some time in March 2012, and your system will crash."
NTP determines what time it is by synchronizing NTP servers with atomic clocks. NTP is based on a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio, or modem. Stratum 2 (secondary) servers are synchronized to stratum 1 servers and so on. Usually, NTP clients and servers connect to Stratum 2 servers.
How do stratum 1 servers sync up with clocks? Many of them use GPSD. This service daemon monitors one or more GPSes for location, course, velocity, and for our purposes, the most important element it tracks is time. This code, which is a mix of a linkable C service library, a C++ wrapper class, and a Python module, has, like all programs, its fair share of bugs. Recently it was discovered that a bug in the time rollback (aka "GPS Week Rollover") sanity checking code scheduled for November 2038 will instead cause 1,024 to be subtracted from the October 24, 2021 week number. In other words, a lot of computers are in for a quick, sharp visit to March 2002.
So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble.
See more in the article....
|
|
|
Has been fixed in gpsd 3.23 and apparently bug is not present in 3.19 and earlier.
Mike W9MDB
On Tuesday, October 19, 2021, 10:10:29 AM CDT, W1RS <deflatermaus@...> wrote:
Info from https://www.zdnet.com/article/thanks-to-a-nasty-gpsd-bug-real-life-time-travel-trouble-arrives-this-weekend/
WSJT users typically utilize frequent time synchronization via upstream time servers on the web. According to this article, "a nasty bug's been uncovered in GPSD that's going to pop up on October 24, 2021. If left unpatched, it's going to switch your time to some time in March 2012, and your system will crash."
NTP determines what time it is by synchronizing NTP servers with atomic clocks. NTP is based on a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio, or modem. Stratum 2 (secondary) servers are synchronized to stratum 1 servers and so on. Usually, NTP clients and servers connect to Stratum 2 servers.
How do stratum 1 servers sync up with clocks? Many of them use GPSD. This service daemon monitors one or more GPSes for location, course, velocity, and for our purposes, the most important element it tracks is time. This code, which is a mix of a linkable C service library, a C++ wrapper class, and a Python module, has, like all programs, its fair share of bugs. Recently it was discovered that a bug in the time rollback (aka "GPS Week Rollover") sanity checking code scheduled for November 2038 will instead cause 1,024 to be subtracted from the October 24, 2021 week number. In other words, a lot of computers are in for a quick, sharp visit to March 2002.
So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble.
See more in the article....
|
|
|
Bill Somerville
Hi Mike and all,
I checked my stratum 1 NTP server,
which is a Raspberry Pi Raspberry Pi OS Linux system. It is using
gpsd 3.17 (as is my 64-bit Rapberry Pi OS system) so I think a lot
of home stratum 1 GPS time servers will be OK without patching. I
would hope that the Debian package maintainers will skip gpsd 3.20
thru 3.22 if they decide to backport a newer version.
73
Bill
G4WJS.
On 19/10/2021 18:27, Michael Black via
groups.io wrote:
toggle quoted message
Show quoted text
Has been fixed in gpsd 3.23
and apparently bug is not present in 3.19 and earlier.
Mike W9MDB
Info from https://www.zdnet.com/article/thanks-to-a-nasty-gpsd-bug-real-life-time-travel-trouble-arrives-this-weekend/
WSJT users
typically utilize frequent time synchronization via
upstream time servers on the web. According to this
article, "a nasty bug's been uncovered in GPSD that's
going to pop up on October 24, 2021. If left
unpatched, it's going to switch your time to some time
in March 2012, and your system will crash."
NTP determines
what time it is by synchronizing NTP servers with
atomic clocks. NTP is based on a hierarchy of levels,
where each level is assigned a number called the
stratum. Stratum 1 (primary) servers at the lowest
level are directly synchronized to national time
services via satellite, radio, or modem. Stratum 2
(secondary) servers are synchronized to stratum 1
servers and so on. Usually, NTP clients and servers
connect to Stratum 2 servers.
How do stratum
1 servers sync up with clocks? Many of them use GPSD.
This service daemon monitors one or more GPSes for
location, course, velocity, and for our purposes, the
most important element it tracks is time. This code,
which is a mix of a linkable C service library, a C++
wrapper class, and a Python module, has, like all
programs, its fair share of bugs. Recently it was
discovered that a bug in the time rollback (aka "GPS
Week Rollover") sanity checking code scheduled for
November 2038 will instead cause 1,024 to be
subtracted from the October 24, 2021 week number. In
other words, a lot of computers are in for a quick,
sharp visit to March 2002.
So, check your
systems now for this problem. And, if, like most of
us, you're relying on someone upstream from you for
the correct time, check with them to make sure they've
taken care of this forthcoming trouble.
See more in
the article....
|
|
|
So where and how is the fix applied to all os's?
|
|
|
Bill Somerville
On 19/10/2021 18:59, AB8WD-Willie via groups.io wrote: So where and how is the fix applied to all os's? Willie, the root problem is in the GPS system, but that is well know and clients must rollover every 1023 weeks to deal with that and the leap second adjustments related to that. This issue is in a service application called gpsd which is used on many systems to interface between GPS receivers and applications like ntpd (a commonly used network time server and client application). The gpsd service had a defect that meant some recent versions of it fail to handle the next GPS rollover correctly. It is not a general operating system problem and only concerns some systems that use GPS receivers directly as an accurate source of time. 73 Bill G4WJS.
|
|
|
Nothing will happen now that’s true. The reason nothing happened in 2000 is because programmers like me started working on this issue even before 1998 to make sure of it.
It wasn’t so much a hoax that something would blow in 2000, many things might have, but thousands of programmers made sure it didn’t. The result of our work was nothing happened in 2000.
|
|
|
William Smith <w_smith@...>
I just fixed my two NTPi boxes, both were running 3.22 (3.17 had some bugs that interfered with my code), but a simple:
sorted it out and upgraded me to 3.23
Your Milage Will Vary, take a backup and know what you are doing.
FWIW: Raspian Buster still has 3.17 as the official 'latest' release, though it's 4 years old. 🤷♂️
73, Willie N1JBJ
On Oct 19, 2021, at 1:47 PM, Bill Somerville < g4wjs@...> wrote:
Hi Mike and all,
I checked my stratum 1 NTP server,
which is a Raspberry Pi Raspberry Pi OS Linux system. It is using
gpsd 3.17 (as is my 64-bit Rapberry Pi OS system) so I think a lot
of home stratum 1 GPS time servers will be OK without patching. I
would hope that the Debian package maintainers will skip gpsd 3.20
thru 3.22 if they decide to backport a newer version.
73
Bill
G4WJS.
On 19/10/2021 18:27, Michael Black via
groups.io wrote:
Has been fixed in gpsd 3.23
and apparently bug is not present in 3.19 and earlier.
Mike W9MDB
WSJT users
typically utilize frequent time synchronization via
upstream time servers on the web. According to this
article, "a nasty bug's been uncovered in GPSD that's
going to pop up on October 24, 2021. If left
unpatched, it's going to switch your time to some time
in March 2012, and your system will crash." NTP determines
what time it is by synchronizing NTP servers with
atomic clocks. NTP is based on a hierarchy of levels,
where each level is assigned a number called the
stratum. Stratum 1 (primary) servers at the lowest
level are directly synchronized to national time
services via satellite, radio, or modem. Stratum 2
(secondary) servers are synchronized to stratum 1
servers and so on. Usually, NTP clients and servers
connect to Stratum 2 servers. How do stratum
1 servers sync up with clocks? Many of them use GPSD.
This service daemon monitors one or more GPSes for
location, course, velocity, and for our purposes, the
most important element it tracks is time. This code,
which is a mix of a linkable C service library, a C++
wrapper class, and a Python module, has, like all
programs, its fair share of bugs. Recently it was
discovered that a bug in the time rollback (aka "GPS
Week Rollover") sanity checking code scheduled for
November 2038 will instead cause 1,024 to be
subtracted from the October 24, 2021 week number. In
other words, a lot of computers are in for a quick,
sharp visit to March 2002. So, check your
systems now for this problem. And, if, like most of
us, you're relying on someone upstream from you for
the correct time, check with them to make sure they've
taken care of this forthcoming trouble. See more in
the article....
|
|
|
This is not a hoax as one member has claimed. Most members just need to be aware of this and keep an eye on their systems over the weekend.
I'm certain there will be compromised versions of GPSD out there.
If anyone does have a problem with this and is unsure how to resolve this I'm sure there is sufficient technical knowledge amongst to advise you.
73
Roger
G4HZA
moderator
|
|
|
But how do I know that the NTP servers I attach my Meinberg NTP clients to have been updated to gpsd 3.23? I’ll just have to check my laptop and shack PC before operating. If I get the wrong date from them then after I repair the date will it get changed again by the next NTP update? 73 Phil GM3ZZA. Sent from Mail for Windows
From: Michael Black via groups.ioSent: 19 October 2021 18:27 To: main@wsjtx.groups.ioSubject: Re: [WSJTX] GPS bug may cause PC time to revert to March 2002 on Oct 24th #AllOperatingSystems #Timesync Has been fixed in gpsd 3.23 and apparently bug is not present in 3.19 and earlier. On Tuesday, October 19, 2021, 10:10:29 AM CDT, W1RS <deflatermaus@...> wrote: Info from https://www.zdnet.com/article/thanks-to-a-nasty-gpsd-bug-real-life-time-travel-trouble-arrives-this-weekend/ WSJT users typically utilize frequent time synchronization via upstream time servers on the web. According to this article, "a nasty bug's been uncovered in GPSD that's going to pop up on October 24, 2021. If left unpatched, it's going to switch your time to some time in March 2012, and your system will crash." NTP determines what time it is by synchronizing NTP servers with atomic clocks. NTP is based on a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio, or modem. Stratum 2 (secondary) servers are synchronized to stratum 1 servers and so on. Usually, NTP clients and servers connect to Stratum 2 servers. How do stratum 1 servers sync up with clocks? Many of them use GPSD. This service daemon monitors one or more GPSes for location, course, velocity, and for our purposes, the most important element it tracks is time. This code, which is a mix of a linkable C service library, a C++ wrapper class, and a Python module, has, like all programs, its fair share of bugs. Recently it was discovered that a bug in the time rollback (aka "GPS Week Rollover") sanity checking code scheduled for November 2038 will instead cause 1,024 to be subtracted from the October 24, 2021 week number. In other words, a lot of computers are in for a quick, sharp visit to March 2002. So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble. See more in the article....
-- 73 Phil GM3ZZA
|
|
|
Bill Somerville
Hi Phil,
that's easy, use the server pools in
the pool.ntp.org organization, they are tested and checked for
accuracy, stability, and availability before being placed in the
pools.
73
Bill
G4WJS.
On 19/10/2021 21:37, Philip Rose via
groups.io wrote:
toggle quoted message
Show quoted text
But how do I know that the NTP servers I
attach my Meinberg NTP clients to have been updated to gpsd
3.23? I’ll just have to check my laptop and shack PC before
operating. If I get the wrong date from them then after I
repair the date will it get changed again by the next NTP
update?
73 Phil GM3ZZA.
Sent from Mail for Windows
Has
been fixed in gpsd 3.23 and apparently bug is not
present in 3.19 and earlier.
Info
from https://www.zdnet.com/article/thanks-to-a-nasty-gpsd-bug-real-life-time-travel-trouble-arrives-this-weekend/
WSJT
users typically utilize frequent time
synchronization via upstream time servers on the
web. According to this article, "a nasty bug's been
uncovered in GPSD that's going to pop up on October
24, 2021. If left unpatched, it's going to switch
your time to some time in March 2012, and your
system will crash."
NTP
determines what time it is by synchronizing NTP
servers with atomic clocks. NTP is based on a
hierarchy of levels, where each level is assigned a
number called the stratum. Stratum 1 (primary)
servers at the lowest level are directly
synchronized to national time services via
satellite, radio, or modem. Stratum 2 (secondary)
servers are synchronized to stratum 1 servers and so
on. Usually, NTP clients and servers connect to
Stratum 2 servers.
How
do stratum 1 servers sync up with clocks? Many of
them use GPSD. This service daemon monitors one or
more GPSes for location, course, velocity, and for
our purposes, the most important element it tracks
is time. This code, which is a mix of a linkable C
service library, a C++ wrapper class, and a Python
module, has, like all programs, its fair share of
bugs. Recently it was discovered that a bug in the
time rollback (aka "GPS Week Rollover") sanity
checking code scheduled for November 2038 will
instead cause 1,024 to be subtracted from the
October 24, 2021 week number. In other words, a lot
of computers are in for a quick, sharp visit to
March 2002.
So,
check your systems now for this problem. And, if,
like most of us, you're relying on someone upstream
from you for the correct time, check with them to
make sure they've taken care of this forthcoming
trouble.
See
more in the article....
--
73 Phil GM3ZZA
|
|
|
Gilbert Baron
Right you are and that was my real point. Programmers will attend to it. Outlook Laptop Gil W0MN Hierro candente, batir de repente 44.08226N 92.51265W EN34rb
From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Keith Kaiser Sent: Tuesday, October 19, 2021 13:11 To: main@WSJTX.groups.io Subject: Re: [WSJTX] GPS bug may cause PC time to revert to March 2002 on Oct 24th Nothing will happen now that’s true. The reason nothing happened in 2000 is because programmers like me started working on this issue even before 1998 to make sure of it. It wasn’t so much a hoax that something would blow in 2000, many things might have, but thousands of programmers made sure it didn’t. The result of our work was nothing happened in 2000. -- W0MN EN34rb 44.08226 N 92.51265 W
Hierro candente, batir de repente
HP Laptop
|
|
|
On 2021-10-19 2:10 PM, Keith Kaiser wrote: The result of our work was nothing happened in 2000. Except that my father passed away the morning of January 1, 2000! He wasn't Y2K compatible and no amount of programming was going to fix that. 73, ... Joe, W4TV On 2021-10-19 2:10 PM, Keith Kaiser wrote: Nothing will happen now that’s true.
The reason nothing happened in 2000 is because programmers like me started working on this issue even before 1998 to make sure of it.
It wasn’t so much a hoax that something would blow in 2000, many things might have, but thousands of programmers made sure it didn’t. The result of our work was nothing happened in 2000.
Keith, WA0̷TJT
|
|
|
William Smith <w_smith@...>
I'm not convinced that ntp.org enforces software version requirements when you add a server to the pool. I don't even know if they can tell if you are using GPSD or not.
I'd _hope_ that if your clock suddenly jumped 1024 weeks into the past that you'd get ignored, but I guess we'll know this weekend. It may depend on what percent of pool servers do the time warp. 🤷♂️
Fortunately, the initial bug report is a couple of months old, and only effects a limited number of releases, so while this is the first _I've_ heard of it, it's not a new problem, as the ZDNet article leads us to believe.
73, Willie N1JBJ
On Oct 19, 2021, at 4:49 PM, Bill Somerville < g4wjs@...> wrote:
Hi Phil,
that's easy, use the server pools in
the pool.ntp.org organization, they are tested and checked for
accuracy, stability, and availability before being placed in the
pools.
73
Bill
G4WJS.
On 19/10/2021 21:37, Philip Rose via
groups.io wrote:
But how do I know that the NTP servers I
attach my Meinberg NTP clients to have been updated to gpsd
3.23? I’ll just have to check my laptop and shack PC before
operating. If I get the wrong date from them then after I
repair the date will it get changed again by the next NTP
update? 73 Phil GM3ZZA. Sent from Mail for Windows
Has
been fixed in gpsd 3.23 and apparently bug is not
present in 3.19 and earlier.
WSJT
users typically utilize frequent time
synchronization via upstream time servers on the
web. According to this article, "a nasty bug's been
uncovered in GPSD that's going to pop up on October
24, 2021. If left unpatched, it's going to switch
your time to some time in March 2012, and your
system will crash." NTP
determines what time it is by synchronizing NTP
servers with atomic clocks. NTP is based on a
hierarchy of levels, where each level is assigned a
number called the stratum. Stratum 1 (primary)
servers at the lowest level are directly
synchronized to national time services via
satellite, radio, or modem. Stratum 2 (secondary)
servers are synchronized to stratum 1 servers and so
on. Usually, NTP clients and servers connect to
Stratum 2 servers. How
do stratum 1 servers sync up with clocks? Many of
them use GPSD. This service daemon monitors one or
more GPSes for location, course, velocity, and for
our purposes, the most important element it tracks
is time. This code, which is a mix of a linkable C
service library, a C++ wrapper class, and a Python
module, has, like all programs, its fair share of
bugs. Recently it was discovered that a bug in the
time rollback (aka "GPS Week Rollover") sanity
checking code scheduled for November 2038 will
instead cause 1,024 to be subtracted from the
October 24, 2021 week number. In other words, a lot
of computers are in for a quick, sharp visit to
March 2002. So,
check your systems now for this problem. And, if,
like most of us, you're relying on someone upstream
from you for the correct time, check with them to
make sure they've taken care of this forthcoming
trouble. See
more in the article....
--
73 Phil GM3ZZA
|
|
|
Bill Somerville
Hi Willie,
servers that contribute to the pool are
remotely monitored for time accuracy, stability, and availability.
This is a continuous cycle, servers are checked roughly every 20
minutes, are scored, and those that don't stay above 10.0 are
bounced from the pools they are in until they improve. Here's the
monitoring page for my stratum 1 server:
It would not be offered to pool
subscribers if it dropped below 10.0 score. As you can see, it is
much harder to regain a score than it is to loose it, hysteresis
is built into the scoring algorithm. Since pool servers are
rotated regularly, an outlier will not cause a subscriber to get
bad time information, assuming they subscribe to 3 or 4 servers
from the pool they use.
73
Bill
G4WJS.
On 19/10/2021 22:25, William Smith
wrote:
toggle quoted message
Show quoted text
I'm
not convinced that ntp.org enforces software version
requirements when you add a server to the pool. I don't even know
if they can tell if you are using GPSD or not.
I'd _hope_ that if your clock suddenly jumped 1024
weeks into the past that you'd get ignored, but I guess we'll
know this weekend. It may depend on what percent of pool
servers do the time warp. 🤷♂️
Fortunately, the initial bug report is a couple of
months old, and only effects a limited number of releases, so
while this is the first _I've_ heard of it, it's not a new
problem, as the ZDNet article leads us to believe.
73, Willie N1JBJ
On Oct 19, 2021, at 4:49 PM, Bill Somerville
< g4wjs@...>
wrote:
Hi Phil,
that's easy, use the
server pools in the pool.ntp.org
organization, they are tested and checked for
accuracy, stability, and availability before being
placed in the pools.
73
Bill
G4WJS.
On 19/10/2021 21:37,
Philip Rose via groups.io wrote:
But how do I know that the
NTP servers I attach my Meinberg NTP clients to
have been updated to gpsd 3.23? I’ll just have
to check my laptop and shack PC before
operating. If I get the wrong date from them
then after I repair the date will it get changed
again by the next NTP update?
73 Phil GM3ZZA.
Sent from Mail for
Windows
Has been fixed in gpsd 3.23 and
apparently bug is not present in 3.19
and earlier.
WSJT users typically utilize
frequent time synchronization via
upstream time servers on the web.
According to this article, "a nasty
bug's been uncovered in GPSD that's
going to pop up on October 24, 2021.
If left unpatched, it's going to
switch your time to some time in March
2012, and your system will crash."
NTP determines what time it
is by synchronizing NTP servers with
atomic clocks. NTP is based on a
hierarchy of levels, where each level
is assigned a number called the
stratum. Stratum 1 (primary) servers
at the lowest level are directly
synchronized to national time services
via satellite, radio, or modem.
Stratum 2 (secondary) servers are
synchronized to stratum 1 servers and
so on. Usually, NTP clients and
servers connect to Stratum 2 servers.
How do stratum 1 servers sync
up with clocks? Many of them use GPSD.
This service daemon monitors one or
more GPSes for location, course,
velocity, and for our purposes, the
most important element it tracks is
time. This code, which is a mix of a
linkable C service library, a C++
wrapper class, and a Python module,
has, like all programs, its fair share
of bugs. Recently it was discovered
that a bug in the time rollback (aka
"GPS Week Rollover") sanity checking
code scheduled for November 2038 will
instead cause 1,024 to be subtracted
from the October 24, 2021 week number.
In other words, a lot of computers are
in for a quick, sharp visit to March
2002.
So, check your systems now
for this problem. And, if, like most
of us, you're relying on someone
upstream from you for the correct
time, check with them to make sure
they've taken care of this forthcoming
trouble.
See more in the article....
--
73 Phil GM3ZZA
|
|
|
Thanks Bill,
What I take from that is that about 20 minutes after midnight on Saturday non-compliant servers will be kicked off the NTP server list. I shall sleep peacefully Saturday night. 73 Phil GM3ZZA
On 19 Oct 2021 22:38, Bill Somerville <g4wjs@...> wrote:
Hi Willie,
servers that contribute to the pool are
remotely monitored for time accuracy, stability, and availability.
This is a continuous cycle, servers are checked roughly every 20
minutes, are scored, and those that don't stay above 10.0 are
bounced from the pools they are in until they improve. Here's the
monitoring page for my stratum 1 server:
It would not be offered to pool
subscribers if it dropped below 10.0 score. As you can see, it is
much harder to regain a score than it is to loose it, hysteresis
is built into the scoring algorithm. Since pool servers are
rotated regularly, an outlier will not cause a subscriber to get
bad time information, assuming they subscribe to 3 or 4 servers
from the pool they use.
73
Bill
G4WJS.
On 19/10/2021 22:25, William Smith
wrote:
I'm
not convinced that ntp.org enforces software version
requirements when you add a server to the pool. I don't even know
if they can tell if you are using GPSD or not.
I'd _hope_ that if your clock suddenly jumped 1024
weeks into the past that you'd get ignored, but I guess we'll
know this weekend. It may depend on what percent of pool
servers do the time warp. 🤷♂️
Fortunately, the initial bug report is a couple of
months old, and only effects a limited number of releases, so
while this is the first _I've_ heard of it, it's not a new
problem, as the ZDNet article leads us to believe.
73, Willie N1JBJ
On Oct 19, 2021, at 4:49 PM, Bill Somerville
< g4wjs@...>
wrote:
Hi Phil,
that's easy, use the
server pools in the pool.ntp.org
organization, they are tested and checked for
accuracy, stability, and availability before being
placed in the pools.
73
Bill
G4WJS.
On 19/10/2021 21:37,
Philip Rose via groups.io wrote:
But how do I know that the
NTP servers I attach my Meinberg NTP clients to
have been updated to gpsd 3.23? I’ll just have
to check my laptop and shack PC before
operating. If I get the wrong date from them
then after I repair the date will it get changed
again by the next NTP update?
73 Phil GM3ZZA.
Sent from Mail for
Windows
Has been fixed in gpsd 3.23 and
apparently bug is not present in 3.19
and earlier.
WSJT users typically utilize
frequent time synchronization via
upstream time servers on the web.
According to this article, "a nasty
bug's been uncovered in GPSD that's
going to pop up on October 24, 2021.
If left unpatched, it's going to
switch your time to some time in March
2012, and your system will crash."
NTP determines what time it
is by synchronizing NTP servers with
atomic clocks. NTP is based on a
hierarchy of levels, where each level
is assigned a number called the
stratum. Stratum 1 (primary) servers
at the lowest level are directly
synchronized to national time services
via satellite, radio, or modem.
Stratum 2 (secondary) servers are
synchronized to stratum 1 servers and
so on. Usually, NTP clients and
servers connect to Stratum 2 servers.
How do stratum 1 servers sync
up with clocks? Many of them use GPSD.
This service daemon monitors one or
more GPSes for location, course,
velocity, and for our purposes, the
most important element it tracks is
time. This code, which is a mix of a
linkable C service library, a C++
wrapper class, and a Python module,
has, like all programs, its fair share
of bugs. Recently it was discovered
that a bug in the time rollback (aka
"GPS Week Rollover") sanity checking
code scheduled for November 2038 will
instead cause 1,024 to be subtracted
from the October 24, 2021 week number.
In other words, a lot of computers are
in for a quick, sharp visit to March
2002.
So, check your systems now
for this problem. And, if, like most
of us, you're relying on someone
upstream from you for the correct
time, check with them to make sure
they've taken care of this forthcoming
trouble.
See more in the article....
--
73 Phil GM3ZZA
--
73 Phil GM3ZZA
|
|
|
William Smith <w_smith@...>
Hi Bill,
Ah, I misunderstood, but now I get it. If even a majority of pool servers do The Time Warp, they'll be removed from the pool within 20 minutes, and people using the pool will only see brief periods of chaos, if that.
Neat, thanks for the clarification!
73, Willie N1JBJ
On Oct 19, 2021, at 5:38 PM, Bill Somerville < g4wjs@...> wrote:
Hi Willie,
servers that contribute to the pool are
remotely monitored for time accuracy, stability, and availability.
This is a continuous cycle, servers are checked roughly every 20
minutes, are scored, and those that don't stay above 10.0 are
bounced from the pools they are in until they improve. Here's the
monitoring page for my stratum 1 server:
It would not be offered to pool
subscribers if it dropped below 10.0 score. As you can see, it is
much harder to regain a score than it is to loose it, hysteresis
is built into the scoring algorithm. Since pool servers are
rotated regularly, an outlier will not cause a subscriber to get
bad time information, assuming they subscribe to 3 or 4 servers
from the pool they use.
73
Bill
G4WJS.
On 19/10/2021 22:25, William Smith
wrote:
I'm
not convinced that ntp.org enforces software version
requirements when you add a server to the pool. I don't even know
if they can tell if you are using GPSD or not.
I'd _hope_ that if your clock suddenly jumped 1024
weeks into the past that you'd get ignored, but I guess we'll
know this weekend. It may depend on what percent of pool
servers do the time warp. 🤷♂️
Fortunately, the initial bug report is a couple of
months old, and only effects a limited number of releases, so
while this is the first _I've_ heard of it, it's not a new
problem, as the ZDNet article leads us to believe.
73, Willie N1JBJ
On Oct 19, 2021, at 4:49 PM, Bill Somerville
< g4wjs@...>
wrote:
Hi Phil,
that's easy, use the
server pools in the pool.ntp.org
organization, they are tested and checked for
accuracy, stability, and availability before being
placed in the pools.
73
Bill
G4WJS.
On 19/10/2021 21:37,
Philip Rose via groups.io wrote:
But how do I know that the
NTP servers I attach my Meinberg NTP clients to
have been updated to gpsd 3.23? I’ll just have
to check my laptop and shack PC before
operating. If I get the wrong date from them
then after I repair the date will it get changed
again by the next NTP update? 73 Phil GM3ZZA. Sent from Mail for
Windows
Has been fixed in gpsd 3.23 and
apparently bug is not present in 3.19
and earlier.
WSJT users typically utilize
frequent time synchronization via
upstream time servers on the web.
According to this article, "a nasty
bug's been uncovered in GPSD that's
going to pop up on October 24, 2021.
If left unpatched, it's going to
switch your time to some time in March
2012, and your system will crash."
NTP determines what time it
is by synchronizing NTP servers with
atomic clocks. NTP is based on a
hierarchy of levels, where each level
is assigned a number called the
stratum. Stratum 1 (primary) servers
at the lowest level are directly
synchronized to national time services
via satellite, radio, or modem.
Stratum 2 (secondary) servers are
synchronized to stratum 1 servers and
so on. Usually, NTP clients and
servers connect to Stratum 2 servers.
How do stratum 1 servers sync
up with clocks? Many of them use GPSD.
This service daemon monitors one or
more GPSes for location, course,
velocity, and for our purposes, the
most important element it tracks is
time. This code, which is a mix of a
linkable C service library, a C++
wrapper class, and a Python module,
has, like all programs, its fair share
of bugs. Recently it was discovered
that a bug in the time rollback (aka
"GPS Week Rollover") sanity checking
code scheduled for November 2038 will
instead cause 1,024 to be subtracted
from the October 24, 2021 week number.
In other words, a lot of computers are
in for a quick, sharp visit to March
2002.
So, check your systems now
for this problem. And, if, like most
of us, you're relying on someone
upstream from you for the correct
time, check with them to make sure
they've taken care of this forthcoming
trouble.
See more in the article....
--
73 Phil GM3ZZA
|
|
|
They might but will sysadmins update the gpsd daemons. 73 Phil GM3ZZA
On 19 Oct 2021 20:50, Gilbert Baron <w0mn00@...> wrote: Right you are and that was my real point. Programmers will attend to it. Outlook Laptop Gil W0MN Hierro candente, batir de repente 44.08226N 92.51265W EN34rb From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Keith Kaiser
Sent: Tuesday, October 19, 2021 13:11
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] GPS bug may cause PC time to revert to March 2002 on Oct 24th Nothing will happen now that’s true. The reason nothing happened in 2000 is because programmers like me started working on this issue even before 1998 to make sure of it. It wasn’t so much a hoax that something would blow in 2000, many things might have, but thousands of programmers made sure it didn’t. The result of our work was nothing happened in 2000.
--
W0MN EN34rb 44.08226 N 92.51265 W
Hierro candente, batir de repente
HP Laptop
--
73 Phil GM3ZZA
|
|
|
Condolences. 73 Phil GM3ZZA
On 19 Oct 2021 20:18, "Joe Subich, W4TV" <lists@...> wrote:
On 2021-10-19 2:10 PM, Keith Kaiser wrote:
> The result of our work was nothing happened in 2000.
Except that my father passed away the morning of January 1, 2000!
He wasn't Y2K compatible and no amount of programming was going to
fix that.
73,
... Joe, W4TV
On 2021-10-19 2:10 PM, Keith Kaiser wrote:
> Nothing will happen now that’s true.
> The reason nothing happened in 2000 is because programmers like me started working on this issue even before 1998 to make sure of it.
>
> It wasn’t so much a hoax that something would blow in 2000, many things might have, but thousands of programmers made sure it didn’t. The result of our work was nothing happened in 2000.
>
> Keith, WA0̷TJT
>
>
--
73 Phil GM3ZZA
|
|
|
Gil, Nothing happened then because we spent a lot of time and money fixing stuff. WB4HXE, Carey
On Tue, Oct 19, 2021 at 12:40 PM Gilbert Baron < w0mn00@...> wrote: Let us not have another Year 2000 flap. Nothing bad happened then and it will not now. Outlook Laptop Gil W0MN Hierro candente, batir de repente 44.08226N 92.51265W EN34rb Has been fixed in gpsd 3.23 and apparently bug is not present in 3.19 and earlier. Info from https://www.zdnet.com/article/thanks-to-a-nasty-gpsd-bug-real-life-time-travel-trouble-arrives-this-weekend/ WSJT users typically utilize frequent time synchronization via upstream time servers on the web. According to this article, "a nasty bug's been uncovered in GPSD that's going to pop up on October 24, 2021. If left unpatched, it's going to switch your time to some time in March 2012, and your system will crash." NTP determines what time it is by synchronizing NTP servers with atomic clocks. NTP is based on a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio, or modem. Stratum 2 (secondary) servers are synchronized to stratum 1 servers and so on. Usually, NTP clients and servers connect to Stratum 2 servers. How do stratum 1 servers sync up with clocks? Many of them use GPSD. This service daemon monitors one or more GPSes for location, course, velocity, and for our purposes, the most important element it tracks is time. This code, which is a mix of a linkable C service library, a C++ wrapper class, and a Python module, has, like all programs, its fair share of bugs. Recently it was discovered that a bug in the time rollback (aka "GPS Week Rollover") sanity checking code scheduled for November 2038 will instead cause 1,024 to be subtracted from the October 24, 2021 week number. In other words, a lot of computers are in for a quick, sharp visit to March 2002. So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble. See more in the article....
--
W0MN EN34rb 44.08226 N 92.51265 W
Hierro candente, batir de repente
HP Laptop
--
--
73, Carey, WB4HXE
|
|
|
On 2021-10-19 4:37 PM, Philip Rose via groups.io wrote: But how do I know that the NTP servers I attach my Meinberg NTP clients to have been updated If you use multiple servers, Meinberg should ignore any with bad times as "false tickers" or "outlyers". I "seed" my NTP configuration file with two or three publicly accessible stratum 1 servers and then use four additional pool servers. The combination of servers should provide sufficient diversity for Meinberg to spot an outlyer. 73, ... Joe, W4TV On 2021-10-19 4:37 PM, Philip Rose via groups.io wrote: But how do I know that the NTP servers I attach my Meinberg NTP clients to have been updated to gpsd 3.23? I’ll just have to check my laptop and shack PC before operating. If I get the wrong date from them then after I repair the date will it get changed again by the next NTP update?
73 Phil GM3ZZA.
Sent from Mail for Windows
From: Michael Black via groups.io
Sent: 19 October 2021 18:27
To: main@wsjtx.groups.io
Subject: Re: [WSJTX] GPS bug may cause PC time to revert to March 2002 on Oct 24th #AllOperatingSystems #Timesync
Has been fixed in gpsd 3.23 and apparently bug is not present in 3.19 and earlier.
https://gitlab.com/gpsd/gpsd/-/issues/144
Mike W9MDB
On Tuesday, October 19, 2021, 10:10:29 AM CDT, W1RS <deflatermaus@...> wrote:
Info from https://www.zdnet.com/article/thanks-to-a-nasty-gpsd-bug-real-life-time-travel-trouble-arrives-this-weekend/
WSJT users typically utilize frequent time synchronization via upstream time servers on the web. According to this article, "a nasty bug's been uncovered in GPSD that's going to pop up on October 24, 2021. If left unpatched, it's going to switch your time to some time in March 2012, and your system will crash."
NTP determines what time it is by synchronizing NTP servers with atomic clocks. NTP is based on a hierarchy of levels, where each level is assigned a number called the stratum. Stratum 1 (primary) servers at the lowest level are directly synchronized to national time services via satellite, radio, or modem. Stratum 2 (secondary) servers are synchronized to stratum 1 servers and so on. Usually, NTP clients and servers connect to Stratum 2 servers.
How do stratum 1 servers sync up with clocks? Many of them use GPSD. This service daemon monitors one or more GPSes for location, course, velocity, and for our purposes, the most important element it tracks is time. This code, which is a mix of a linkable C service library, a C++ wrapper class, and a Python module, has, like all programs, its fair share of bugs. Recently it was discovered that a bug in the time rollback (aka "GPS Week Rollover") sanity checking code scheduled for November 2038 will instead cause 1,024 to be subtracted from the October 24, 2021 week number. In other words, a lot of computers are in for a quick, sharp visit to March 2002.
So, check your systems now for this problem. And, if, like most of us, you're relying on someone upstream from you for the correct time, check with them to make sure they've taken care of this forthcoming trouble.
See more in the article....
|
|
|
