[time-nuts] Re: Telstra outage: Possible GPS-related 1024 week rollover.

[Steven Sommars]

I received these notes from Bil Dos, a security researcher.  Further
discussion of this particular incident seems outside the normal scope of
time-nuts.


(first note)

What Telstra has officially confirmed so far: the outage began around 4:20
am AEST on Wednesday 8 July when a time node in one of its Sydney or
Melbourne data centres came back with the wrong time after being restarted
while it was being worked on, and the wrong time then propagated across the
network. On Thursday, CFO Michael Ackland confirmed to reporters that parts
of the network momentarily set their date back to November 2006. He
explicitly rejected the Y2K comparison and described it as a software
glitch that reset the GPS timer. No vendor, model, or firmware version has
been publicly identified, so the direct answer to your question is:
unknown. Nothing in the public record names the hardware.


Why WNRO is nonetheless the only hypothesis that predicts the evidence: 8
July 2026 minus exactly 1,024 weeks (7,168 days) is 22 November 2006, to
the day. Full GPS week 2426 and week 1402 broadcast the same truncated
10-bit value, 378, so they are indistinguishable in the legacy frame. Day
of week is preserved (both dates are Wednesdays) and the offset is
congruent with the GPS week grid anchored at 6 January 1980. Random
corruption, timezone bugs, or NTP parsing errors have no reason to land on
the one date out of tens of thousands that is the modulo-1024-week shadow
of the true date.


On the SyncServer S200/S300 advisory (internal WNRO on 18 September 2022):
the date mismatch is not evidence against the WNRO class, and this is the
operationally interesting part. For receivers that mask a lapsed firmware
pivot with volatile state (a continuously incrementing internal clock or a
sliding window), the advisory date is when the defect arms, not when it
fires. A unit past its pivot keeps computing correct time for as long as it
runs uninterrupted. The next cold restart clears that state, the receiver
re-resolves the raw 10-bit week against the lapsed pivot, and lands 1,024
weeks in the past as of the restart date, not the advisory date. Telstra's
confirmed trigger, a restart during works at 4:20 am, is exactly that
failure signature. An unsupported unit with a 2022-class internal rollover,
restarted in July 2026, computes precisely November 2006. I am not claiming
Telstra ran SyncServers; I am saying the advisory date excludes nothing.


Precedent for off-schedule, receiver-specific WNRO is well established:
Honda and Acura head units worldwide jumped to 2002 on 1 January 2022
(diagnostic menus showed an internal date exactly 1,024 weeks in the past,
and Honda correctly predicted self-correction for August 2022), the same
fleet had jumped to 1998 in 2017, and the 2021 gpsd bug remains the one
case in this class with a fully public root cause, since the code is open.


ACMA has opened a formal investigation and Telstra has 45 days to report,
so the offending model may yet surface there. Until then, a WNRO exposed by
cold restart of a lapsed-pivot receiver is the only mechanism consistent
with every confirmed data point: the destination date, the day-of-week
preservation, the restart trigger, and the pre-dawn works window.

(second note)

Quick update, and you were right to point at that advisory family. The
device has now been named in the press, and it is exactly the one your
bulletin covers.

Per ACS Information Age (12 July), the outage has been pinned on an
obsolete Symmetricom SyncServer S300 node that manages time on the network,
which reset its 10-bit week counter to zero on the 1,024-week boundary and
sent the device back to 2006. That is the same S200/S300 family as FSB
098-50620-106, with the Furuno GPS receiver, discontinued in 2016. So the
answer to your earlier question, what were the offending GPS models, is
now: a SyncServer S300.

Link:
https://ia.acs.org.au/article/2026/telstra-outage-blamed-on-known-bug-in-obsolete-server.html

This also resolves the point about the advisory covering a different date
(18 September 2022 internal rollover). As the bulletin itself warns, that
date is when the defect arms, not when it fires. An affected unit keeps
serving correct time until it is made to re-acquire the constellation from
a cleared state; the next reacquisition then locks it 1,024 weeks in the
past, measured from the reacquisition, not from the advisory date. A unit
reacquiring on 8 July 2026 computes November 2006, which is precisely what
Telstra confirmed. The 18 September 2022 date being in the past is exactly
consistent with the failure, not evidence against it.

Two further points now on the record:
- Telstra CEO Vicki Brady has admitted the time-server bug was known about
beforehand. Replacement cost is reported under 30,000 dollars; the Triple
Zero failures carry fines up to 30 million.
- Executives front a Senate Environment and Communications References
Committee hearing on Friday, alongside ACMA, Triple Zero Custodian and
internal investigations, so a formal root cause with firmware-level detail
may follow.

The arithmetic held up end to end: 8 July 2026 minus 1,024 weeks is 22
November 2006, day of week preserved, on the exact model your advisory
flagged. Thanks for the sharp pointer to the FSB.