AW: Speedport W 724V + Systemzeit (Sommer-/Winterzeit, Zeitumstellung)

[#1]

Hallo Mitleser & Helfer,

weiß jemand warum sich der Speedport W 724V Typ B nicht selbstständig auf Winterzeit umstellt?

So etwas hatte ich in all den Jahren noch nie gehabt.

Ein Reboot konnte das Problem leider nicht lösen.

In den Systemmeldungen wird mehrmals suggeriert das die Systemzeit erfolgreich aktualisiert wurde.

Hat von euch jemand das gleiche Problem? Vielleicht auch mit einem aktuelleren Speedport?

Wie kann man die Zeitumstellung beim Speedport erzwingen?

Werksreset habe ich noch nicht gemacht. (Will ich auch erstmal nicht. ;-))

Hier noch ein paar Screenshots:

Mehr Infos

— Systemmeldungen —

------------- Zusammenfassung: Heute, 25. Oktober 2020, 17:28:57 -------------

25.10.2020 18:22:44 Die Systemzeit wurde erfolgreich aktualisiert (T101)
25.10.2020 18:22:10 DSL ist verfügbar (DSLSynchronisierung besteht). (R007)
25.10.2020 18:17:07 Es wurde ein Reboot ausgelöst. (B103)
> Hier wird die Systemzeit immer noch nach Sommerzeit ausgegeben.

...

25.10.2020 15:06:43 Die IPv6 Systemzeit wurde erfolgreich aktualisiert (NT101)
25.10.2020 09:06:42 Die IPv6 Systemzeit wurde erfolgreich aktualisiert (NT101)
25.10.2020 03:06:40 Die IPv6 Systemzeit wurde erfolgreich aktualisiert (NT101)

========================== E N D E ===============================

— Abfrage des NTP-Servers zwecks Genauigkeit —
Sieht soweit in Ordnung aus.

Falls ich irgendwas vergessen habe zu erwähnen, bitte fragt mich.

[#2 · Accepted solution]

Hallo zusammen,

nach der letzten Zeitumstellung vom 25.10.2020 wurde die Uhrzeit auf Speedphone Displays teilweise nicht auf die Winterzeit angepasst.

Der Fehler tritt nach derzeitigem Erkenntnisstand mit folgenden Geräten auf: Speedport W 724V Typ A, B und C, Speedport W 922V und Speedport W 723V Typ A, jeweils unabhängig von der Firmware-Version.

Es handelt sich um einen Fehler in einem lizenzierten Linux-Modul älterer Speedport-Router. Die korrekte Uhrzeit wird wieder ab dem 01.11.2020 dargestellt. Es muss nichts unternommen werden.

Wir möchten euch daher weiter um Geduld bitten. Am kommenden Sonntag sollte alles wieder passen.

Viele Grüße

Schmidti

[#3]

@RoadrunnerDD 

wurde weiter oben doch schon erklärt ...

[#4]

---

@RoadrunnerDD  schrieb:
So rein Interesse halber ... kann das mal jemand genauer erläutern wann das, wieso, wesshalb und warum nun genau aufgetreten ist, auftreten wird und wann nicht .... ?

---

Dieser Fehler tritt nur unter besonderen Umständen auf, da im Linux-Kernel ein fehlerhafter Algorithmus programmiert wurde.

Für die betroffenen Speedports gilt die Zeitumstellung immer sonntags in der vierten Kalenderwoche jeweils im März und Oktober. (konstant)

Das ist rechnerisch falsch, da die Zeitumstellung immer am letzten Sonntag jeweils im März und Oktober stattfindet.

In manchen Jahren verschiebt sich die Zeitumstellung dadurch um 7 Tage nach hinten.

Ich hoffe mal, ich konnte es verständlich erklären.

Sachliche Formulierungen sind nicht so mein Ding.

[#5]

@RoadrunnerDD 

Per Definition ist die Umschaltung von Winterzeit auf Sommerzeit der letzte Sonntag im März und die Umschaltung von Sommerzeit auf Winterzeit der letzte Sonntag im Oktober.

Jetzt haben aber die Programmierer offensichtlich Samstag mit Sonntag verwechselt.

Der letzte Samstag im Oktober 2020 ist der 31., also wird am Sonntag, dem 1.11.2020 auf Winterzeit umgestellt.

[#6]

Grundsätzlich ist mir das schon klar, aber die Erklärungen hauen alle irgendwie nicht hin ... denn der Sonntag der 4. Woche des Oktobers ist immernoch der 25.10. nur das es halt der erste Tag der 4. Woche ist ... dementsprechend gibt es hier ja auch 2 Meinungen, wann das wieder auftreten wird .... einmal das es noch 7x auftreten wird, und einmal das es nur 10/2026 auftreten wird...

*KnotenImKopf*

[#7]

Das Problem tritt nur auf, wenn der 31.03. bzw. der 31.10. ein Samstag ist. Eine Woche beginnt, je nach Definition am So (war früher bei uns auch so) oder am Mo und die erste Woche eines Jahres / Monats muss 4 bzw. x (auch unterschiedlich definiert) Tage haben.

[#8]

---

@RoadrunnerDD  schrieb:

Grundsätzlich ist mir das schon klar, aber die Erklärungen hauen alle irgendwie nicht hin ...

---

Es kommt drauf an wie man den Kalender liest.

Die tatsächliche Zeitumstellung fand in der 3. Kalenderwoche statt.

Für die betroffenen Speedports endet die 4. Kalenderwoche am 01.11.

[#9]

Dankeschön für die Info.

Ich hoffe,dass es dann auch so klappt

[#10]

Bitte das Attribut "gelöst" entfernen.
Denn es ist kein Problem mit der Linux-Version der Router.

Der Fehler kommt daher, dass der NTC-Zeitserver in den USA steht.
Dort wird allerdings erst am 1.11.2020 auf Normalzeit umgestellt.
(Normalzeit = umgangssprachlich Winterzeit).

[#11]

@cornelia_helbig 

Das ist, mit Verlaub, die dümmste Antwort.

Ein ntp-Server kennt keine Sommerzeit/Winterzeit.

Der liefert nur UTC (GMT).

[#12]

---

@cornelia_helbig  schrieb:

Denn es ist kein Problem mit der Linux-Version der Router.

Der Fehler kommt daher, dass der NTC-Zeitserver in den USA steht.

---

Wenn dem so wäre, dann wären alle Telekom-Router von diesem Problem betroffen.

Meine Windows-Version kommt ebenfalls aus den USA, dennoch wird die Systemzeit auf dem PC von der physikalisch-technischen Bundesanstalt Braunschweig empfangen.

Die Telekom nutzt diesen Zeitserver: ntp1.t-online.de

[#13]

---

@Gelöschter Nutzer  schrieb:

---

@RoadrunnerDD  schrieb:

Grundsätzlich ist mir das schon klar, aber die Erklärungen hauen alle irgendwie nicht hin ...

---

Es kommt drauf an wie man den Kalender liest.

Die tatsächliche Zeitumstellung fand in der 3. Kalenderwoche statt.

Für die betroffenen Speedports endet die 4. Kalenderwoche am 01.11.

---

Genau diese Begründung scheint ja aber eben falsch zu sein ... da die Linux-Woche Sonntag beginnt.

[#14]

Ich denke in den Untiefen des Netzes es gefunden zu haben ... und zwar tritt das Problem ...

---

@kurz59  schrieb:

[...] nur auf, wenn der 31.03. bzw. der 31.10. ein Samstag ist. [...]

---

UND das ganze ein Schaltjahr ist.

Somit trat das Problem auf am

25.03.2012

25.10.2020

und wird wieder auftreten:

NICHT am 25.10.2026

sondern erst wieder am 25.03.2040

und weiter am 25.10.2048 usw...

wenn bis dahin immer noch ein Gerät mit der entsprechend alten Version (der uCLib übrigens) laufen sollte

[#15]

---

@RoadrunnerDD  schrieb:

UND das ganze ein Schaltjahr ist.

Somit trat das Problem auf am

25.03.2012

...

---

Interessanter Gedanke.

Schaltjahr! Daran habe ich nun gar nicht gedacht.

Läßt sich das noch zurückverfolgen, ob das Problem am 25.03.2012 beim W 723V Typ A auftrat?

Die 724er Serie gab es bis Dato noch nicht.

[#16]

Ich muss mich korrigieren:

Dieses Problem ist am 25.10.2020 letztmalig aufgetreten! Betreffende Systeme werden die Jahre 2039ff nicht erreichen, da der Unixzeitstempel (32bit) am 19.01.2038 04:14:08 (CET) überläuft und auf 13.12.1901 21:45:52 springt

🤣

[#17]

---

@RoadrunnerDD  schrieb:

Ich muss mich korrigieren:

Dieses Problem ist am 25.10.2020 letztmalig aufgetreten! Betreffende Systeme werden die Jahre 2039ff nicht erreichen, da der Unixzeitstempel (32bit) am 19.01.2038 04:14:08 (CET) überläuft und auf 13.12.1901 21:45:52 springt

🤣

---

Na wenigstens kommen wir jetzt der Ursache immer näher.

Das sah am Sonntag noch nicht danach aus.

Hast du den Quelltext aus dem Linux-Kernel ausgelesen, oder woher stammt die Info?

Ich habe es leider zeitlich noch nicht geschafft.

[#18]

Damit hingen doch auch die Jahr 2000 Befürchtungen zusammen 🤔

[#19]

---

@kurz59  schrieb:

Damit hingen doch auch die Jahr 2000 Befürchtungen zusammen 🤔

---

Meinst du die Panikschieberei von damals?

Ich erinnere mich.

[#20]

Ja, genau.

[#21]

---

@kurz59  schrieb:

Ja, genau.

---

Na, die Atombomben sind nicht unkontrolliert hochgegangen.

Alles gut. 😀

[#22]

Na dann warten wir das mal ab. Wäre ja schön wenn dann wieder alles klappt. 

[#23]

Für diejenigen, welche das interessiert ... und das verstehen können was da steht ... -> siehe Bildchen

PS.: nicht nur Speedports kämpfen damit .... ich habe beruflich auch mit Embedded-Linux-Systemen zu tun, davon auch ältere bei Kunden seit vielen Jahren laufen, und einer davon beschwerte sich heute per Mail über die falsche Zeit auf seinen alten Geräten ... da viel mir prompt ein das Problem hier gelesen zu haben 😂🤣 und erinnerte mich daran, was noch kommt (2038) sollten es die Geräte bis dahin schaffen

[#24]

Das Problem wurde schon 2011 beschrieben.

https://lists.uclibc.org/pipermail/uclibc/2011-October/045825.html

[#25]

---

@Gelöschter Nutzer  schrieb:

---

[...]

Läßt sich das noch zurückverfolgen, ob das Problem am 25.03.2012 beim W 723V Typ A auftrat?

---

zumindest bei AVM tat es das ... https://www.heise.de/newsticker/meldung/Fritz-Boxen-verschlafen-Zeitumstellung-1479870.html

[#26]

---

@RoadrunnerDD  schrieb:

...was noch kommt (2038) sollten es die Geräte bis dahin schaffen

---

Soweit müssen es die betroffenen Speedports nicht schaffen.

In 18 Jahren ist die Technik soweit entwickelt, das niemand mehr diese Speedports einsetzen will.

Wer geht heute noch mit einem 56k Modem ins Netz?

[#27]

Ah, jetzt erinnere ich mich wieder.

-    if (isleap && (r->month > 1)) {

+    if (isleap && (r->month == 2)) {

Wirklich ziemlich blöder Fehler.