Jahr 2017 oder 2035 in Fritzbox?

[itzy]

Ein kaputter Zeitserver würde nur erklären, wenn es eine falsche Uhrzeit gibt. Siehe Threadtitel und diverse Beiträge, es wurden aber verschiedene Uhrzeiten beobachtet.

 

[cuma]

Ich hab mal den Start einer 7170 mit FW .67 Freetz-Trunk ohne openntpd mit tcpdump mitgeloggt. Es wird der Zeitserver 0.europe.pool.ntp.org aufgelöst nach

A 131.234.137.23
A 204.9.53.11
A 195.214.215.17
A 193.62.22.82
A 212.201.68.154

Es kam eine NTP Anfrage und korrekte Antwort an/vom ersten Server "Mainflingen". Soweit alles ok


Und das Syslog der 7270, auch FW .67 Trunk ohne openntpd sagt beim reboot (Zeit ist also noch vorhanden?)

Dec 29 00:28:45 telefon[1567]: set initial telefon time from linux time to 0:28 29.12 2008!
Dec 29 00:28:45 chronyd[1751]: System's initial offset : 0.003389 seconds fast of true (slew)
Dec 29 00:28:46 chronyd[1751]: Could not send to 147.231.100.5 : Bad file descriptor
Dec 29 00:28:46 chronyd[1751]: Could not send to 0.0.0.0 : Bad file descriptor
Dec 29 00:28:47 chronyd[1751]: Could not send to 147.231.100.5 : Bad file descriptor
Dec 29 00:28:47 chronyd[1751]: Could not send to 0.0.0.0 : Bad file descriptor
Dec 29 00:28:48 chronyd[1751]: Could not send to 147.231.100.5 : Bad file descriptor
Dec 29 00:28:48 chronyd[1751]: Could not send to 0.0.0.0 : Bad file descriptor

Versuch 2

Jan  1 01:00:57 chronyd[1887]: chronyd version 1.23 starting
Jan  1 01:00:58 chronyd[1887]: Initial txc.tick=10000 txc.freq=0 (0.00000000) txc.offset=0 => hz=100 shift_hz=7
Jan  1 01:00:58 chronyd[1887]: set_config_hz=0 hz=100 shift_hz=7 basic_freq_scale=1.28000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000
Jan  1 01:00:58 chronyd[1887]: Linux kernel major=2 minor=6 patch=19
Jan  1 01:00:58 chronyd[1887]: calculated_freq_scale=0.99902439 freq_scale=0.99902439
Jan  1 01:00:58 chronyd[1887]: Could not open /dev/rtc, No such file or directory
Jan  1 01:00:58 chronyd[1887]: Real time clock not supported on this operating system
Dec 29 00:50:08 telefon[1602]: set initial telefon time from linux time to 0:50 29.12 2008!
Dec 29 00:50:09 chronyd[1887]: System's initial offset : 0.004700 seconds slow of true (slew)
Dec 29 00:50:09 chronyd[1887]: Could not send to 91.121.73.63 : Bad file descriptor
Dec 29 00:50:10 chronyd[1887]: Could not send to 0.0.0.0 : Bad file descriptor
Dec 29 00:50:10 chronyd[1887]: Could not send to 91.121.73.63 : Bad file descriptor
Dec 29 00:50:11 chronyd[1887]: Could not send to 0.0.0.0 : Bad file descriptor
Dec 29 00:50:11 chronyd[1887]: Could not send to 91.121.73.63 : Bad file descriptor
Dec 29 00:50:12 crond[1718]: time disparity of 4730389 minutes detected
Dec 29 00:50:12 chronyd[1887]: Could not send to 0.0.0.0 : Bad file descriptor

 

[vice_pres]

Das mit dem Bad file descriptor kann ich bestätigen:

Dec 29 05:57:33 fritz daemon.err chronyd[4625]: Could not open /dev/rtc, No such file or directory
Dec 29 05:57:33 fritz daemon.err chronyd[4625]: Real time clock not supported on this operating system
Dec 29 05:57:34 fritz daemon.info chronyd[4625]: System's initial offset : 0.037922 seconds fast of true (slew)
Dec 29 05:57:35 fritz daemon.warn chronyd[4625]: Could not send to 217.147.223.78 : Bad file descriptor
Dec 29 05:57:36 fritz daemon.warn chronyd[4625]: Could not send to 217.147.223.78 : Bad file descriptor
Dec 29 05:57:37 fritz daemon.warn chronyd[4625]: Could not send to 217.147.223.78 : Bad file descriptor

 

[wollet42]

Ist das eigentlich nur ein Problem der letzten release version oder auch bei der neuen Labor bzw bei den letzten alten all in one Labors beobachtet worden?

 

[frank_m24]

Hallo,

wenn es nicht an Freetz liegt, dann ist die Phone Labor definitiv auch betroffen.

 

[itzy]

*Schieb*

Hat das Problem sonst niemand? Bei mir tritt das Problem immer noch auf, primär in der Anrufliste mit unterschiedlichen Zeiten. Januar 2018 und Juli 2013 sind es bei mir gerade.

2017 habe ich seit dem Jahreswechsel nicht mehr gesehen: das spricht für eine konstante Verschiebung.

Kann jemand die Zeiten oben bestätigen, oder treten gerade auch andere auf?

 

[cgabriel]

I habe exactly the same thing.
Strange is, everything else seems OK (Internettelefonie/Sprachübertragung or Ereignisse, "date" command) with the exception of call list!

Historically, there was a point (after a fw update) where the whole system date/time was wrong (all above dates). It seems that it failed to update from NTP.
I found somewhere that after using once "date" command (see format, from telnet, then immediately reboot), then everything was OK except the call list (I tried to clear/disable/reenable it).

I don't have too much time to invest into this, but maybe this info could help someone with more linux experience.

PS: in my call list, the last date is "06.01.14 11:31"

Regards,
Gabriel

 

[elmicha]

Ich habe das Problem auch - in der Anrufliste ist der letzte Anruf vom 15.07.13, die Ausgabe von date und die Angaben in /var/log/messages sind ok.

openntpd statt chrony hat nichts geändert (abgesehen davon, dass ich nach dem Booten und DSL-Neusynchronisation "/etc/init.d/rc.openntpd restart" aufrufen muss, damit die Ausgabe von "date" stimmt).

Von welchem Programm bekommt die Anrufliste ihre Zeit? Könnte man dieses Programm einfach neustarten?

 

[vice_pres]

Ist bei mir heute auch nochmal aufgetreten - chrony neustart hat auch die Systemzeit nicht geändert... Es half nur ein reboot.

Zum glück hab ich avmfirewall drauf und mir nen ssh Zugang freigeschaltet, da das Openvpn nicht hochkam, da der handshake wegen des großen Zeitunterschiedes nicht zustandekam.

Nachwievor kann ich es nicht verstehen...

@elmicha: Die Anrufliste bekommt es imho vom chronyd - allerdings hat bei mir ein neustart desselbigen nix gebracht

 

[Silent-Tears]

Ich bekommme hier tatsächlich nur eine einigermasen vernünftige systemzeit, wenn ich openntpd aus dem Image draussen lasse. Zusammen wollen die einfach nicht ohne persönliche Intervention miteinander "spielen"

 

[wollet42]

Liegt das problem nur bei freetz boxen vor oder auch bei original avm?

PS ich habs auch ohne openntpd

 

[Silent-Tears]

Ich hab zusätzlich noch das tr069 ausgestellt. OB das nun die Auswirkung war, kann ich aber nicht sagen, denn vorher gabs ständige Versuche, irgendwelche Sachen mit dem Provider auszumachen.
Bin erst seit vorhin 1&1-Kunde und hab denen ihren Spass gelassen, einmal die Config richtig zu richten. Danach gleich freetz drauf, Branding geändert, und eben tr069 aus. Letzteres allerdings erst, nachdem ich openntpd wieder aus dem Image geworfen hab.

 

[leo22]

Heute ist nun bei mir auch der 09.03.2018 :-(

Im Log steht bei mir dasselbe wie bei den anderen hier im Thread

Feb  3 20:38:27 fritz daemon.err chronyd[1323]: [COLOR=Red]Could not open /dev/rtc[/COLOR], No such file or directory
Feb  3 20:38:27 fritz daemon.err chronyd[1323]: Real time clock not supported on this operating system

Im Anrufbeantworter-Thread hatte ich festgestellt, dass es statt rtc (in der Original-FW) in Freetz nur rtc0 gibt. Kann das das Problem sein?

 

[cando]

Tja, Du warst schon immer Deiner Zeit weit voraus....:gruebel:

 

[leo22]

Bei mir ist das Zeit-Problem erst aufgetreten, nachdem die vorher nicht korrekt geladenen AVM-Plugins richtig eingebunden waren (und der Anrufbeantworter nun wieder funktioniert).

 

[geiercasi]

hier selbiges problem. gelgentlich werden anrufe ein paar jahre im voraus gelogt. aufgetreten ist der fehler nach dem einspielen der freetz version über das backend (wie bei leo). die box selbst hat die korrekte uhrzeit. nur die anruferliste spinnt....

gruß

 

[olistudent]

Könnt ihr das bitte nochmal genauer beschreiben?
Was habt ihr wie geflasht? Dann schau ich mal, ob ich das nachvollziehen kann.

MfG Oliver

 

[zirkon]

Habe das Problem die letzten Tage auch zwei oder drei mal beobachten können. Das MT-D lebt dann auch in der Zukunft. Nach einem Reboot war das Datum jedoch wieder richtig. Habe jetzt mal openntpd entfernt und werde die Geschichte weiterhin beobachten. Habe leider die letzten Tage zu viel ausprobiert um den Auslöser genauer ausmachen zu können. Firmware wurde bisher immer via AVM-webif geflasht.

 

[geiercasi]

Könnt ihr das bitte nochmal genauer beschreiben?
Was habt ihr wie geflasht? Dann schau ich mal, ob ich das nachvollziehen kann.

MfG Oliver

wir haben aufgrund des plugin problems ein aio freetz für die 7270 per backend im freetz hochgeladen. auf diese weise lief dann der ab wieder. vorher habe ich die images per push-firmware aufgespielt.
seit dem einspielen per backend im freetz hat die box gelegentlich anrufer im jahr 2013.

gruß

 

[leo22]

aufgetreten ist der fehler nach dem einspielen der freetz version über das backend (wie bei leo).

Also scheint die Uhr nur falsch zu gehen wenn die Plugins geladen sind.

Kann mir mal jemand erklären wie das überhaupt mit dem chrony funktioniert?

Gibt es in der FRITZ!Box eine echte RTC? Sicher nicht. Die Box enthält keine Batterie und beim Neustart der Box hat diese ja nie die korrekte Uhrzeit, diese holt sie sich immer aus dem Netz. Aber was ist dann /dev/rtc ? Ist rtc nur angelegt und hat keine Funktion? Das würde auch die Meldung "Real time clock not supported on this operating system" erklären. Wird also chrony nur verwendet, um eine nur zur Laufzeit vorhandene Uhr zu synchronisieren? Da wäre die Fehlermeldung gar keine im eigentlichen Sinne.

Noch was anderes: Wenn AVM nun schon chrony eingebaut hat, kann man dann nicht dieses in Freetz konfigurierbar machen und es statt openntp verwenden? Bei chrony lässt sich sehr viel konfigurieren (z. B. auch das rtcdevice, falls es doch rtc0 und nicht rtc heißen sollte). Siehe dazu den sehr ausführlichen User Guide, eine deutsche Seite zu chrony gibt es auch.