GPS D (i.e. gpsd) roll over bug..Oct 24th
For those using GPSD (https://gpsd.gitlab.io/gpsd/index.html https://gpsd.gitlab.io/gpsd/index.html) to read GPS receivers, and get the GPS time, there is a bug that could cause problems on Oct 24th.
https://us-cert.cisa.gov/ncas/current-activity/2021/10/21/gps-daemon-gpsd-rollover-bug https://us-cert.cisa.gov/ncas/current-activity/2021/10/21/gps-daemon-gpsd-rollover-bug
KR, K6TD
Hi,
On 2021-10-22 17:58, Kevin Rowett wrote:
For those using GPSD (https://gpsd.gitlab.io/gpsd/index.html https://gpsd.gitlab.io/gpsd/index.html) to read GPS receivers, and get the GPS time, there is a bug that could cause problems on Oct 24th.
https://us-cert.cisa.gov/ncas/current-activity/2021/10/21/gps-daemon-gpsd-rollover-bug https://us-cert.cisa.gov/ncas/current-activity/2021/10/21/gps-daemon-gpsd-rollover-bug
I find it amusing, as this was discussed on ntp-questions email-list in
mid August 2013, and clearly explained with due references. It seems
that people did not act. There was a misconception that this was a
"receiver error" for which they should not do any fixes. It's actually a
systemflaw that never was fixed in L1 C/A code. It would have been good
if they added additional GPS-weeks bits in that signal, but it never
materialized. It did for other newer signals.
It seems nothing happen in those 8 years until the patching this year.
Cheers,
Magnus
”It's actually a systemflaw that never was fixed in L1 C/A code. It would have been good if they added additional GPS-weeks bits in that signal, but it never materialiseras. It did for other newer signals.”
The L1 C/A was optimised many decades ago. How Do you change the bitstream definition, considering several satellite generations running in parallel. Some approaching 20 years since launch. Many years more since design.
How do you ensure that old and current working C/A-code receivers don’t turn into unusable crap? (Including the systems they reside in)
Systemflaw... for a system designed now yes. For one designed in the 70-ties, still running the show No. Not in my view.
/Björn
Hi
As various GPS module designs done over the last decade or so have shown, you can
fix this at the module level. Yes, each of those fixes has its drawbacks. However, the modern
designs are a lot less likely to “die” 10 or 20 years from now.
….. and to address the inevitable follow up question:
The receiver can “save” the last date it saw. That becomes the “never before” date. If this is
enabled and the receiver gets a spoofed date, that’s a problem.
You can manually enter a “never before” date. That works fine, except for the “manual” part….
Anything that can be done manually could also be done under the control of the driver. That
opens a hacking path. There are a lot of things that could brick a receiver if the driver is hacked
so this is hardly unique in that regard.
Bob
On Oct 22, 2021, at 1:22 PM, Magnus Danielson via time-nuts time-nuts@lists.febo.com wrote:
Hi,
On 2021-10-22 17:58, Kevin Rowett wrote:
For those using GPSD (https://gpsd.gitlab.io/gpsd/index.html https://gpsd.gitlab.io/gpsd/index.html) to read GPS receivers, and get the GPS time, there is a bug that could cause problems on Oct 24th.
https://us-cert.cisa.gov/ncas/current-activity/2021/10/21/gps-daemon-gpsd-rollover-bug https://us-cert.cisa.gov/ncas/current-activity/2021/10/21/gps-daemon-gpsd-rollover-bug
I find it amusing, as this was discussed on ntp-questions email-list in mid August 2013, and clearly explained with due references. It seems that people did not act. There was a misconception that this was a "receiver error" for which they should not do any fixes. It's actually a systemflaw that never was fixed in L1 C/A code. It would have been good if they added additional GPS-weeks bits in that signal, but it never materialized. It did for other newer signals.
It seems nothing happen in those 8 years until the patching this year.
Cheers,
Magnus
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
Björn,
The C/A code format have seen much greater changes before that. It's
extention from 24 to 32 birds was not small, neither was the addition of
the GPS-UTC corrections.
Cheers,
Magnus
On 2021-10-22 21:29, Björn wrote:
”It's actually a systemflaw that never was fixed in L1 C/A code. It would have been good if they added additional GPS-weeks bits in that signal, but it never materialiseras. It did for other newer signals.”
The L1 C/A was optimised many decades ago. How Do you change the bitstream definition, considering several satellite generations running in parallel. Some approaching 20 years since launch. Many years more since design.
How do you ensure that old and current working C/A-code receivers don’t turn into unusable crap? (Including the systems they reside in)
Systemflaw... for a system designed now yes. For one designed in the 70-ties, still running the show No. Not in my view.
/Björn
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-leave@lists.febo.com
To unsubscribe, go to and follow the instructions there.
On Fri, October 22, 2021 12:22 pm, Magnus Danielson via time-nuts wrote:
I find it amusing, as this was discussed on ntp-questions email-list in
mid August 2013, and clearly explained with due references.
According to the problem report this problem was only introduced in 2019,
so seems to be a regression rather than a problem left uncorrected since
2013.
--
Chris Caudle
Chris,
On 2021-10-22 22:18, Chris Caudle wrote:
On Fri, October 22, 2021 12:22 pm, Magnus Danielson via time-nuts wrote:
I find it amusing, as this was discussed on ntp-questions email-list in
mid August 2013, and clearly explained with due references.
According to the problem report this problem was only introduced in 2019,
so seems to be a regression rather than a problem left uncorrected since
2013.
This is correct, but the bug re-introduces the 1024 wrapping issue,
which should have a basic safetynet after it.
Cheers,
Magnus
Björn writes:
The L1 C/A was optimised many decades ago.
The first GPS receiver to use the L1 C/A code took up four full
racks and required to very alert persons to operate.
There is a picture of it in one of the many "History of GPS"
presentations given by the principals of the programme.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.