Jahr 2017 oder 2035 in Fritzbox?

[frank_m24]

Hallo,

grade die Rufliste war nach dem Update per Telefon korrekt. Den Rest der Systemzeiten konnte ich auch per Konsole ändern.

 

[zirkon]

Habe mal die Rufliste gelöscht. Komischerweise stimmen die Zeiten nun wieder. Weiter beobachten

 

[cuma]

Auf der 7170 war auch noch nie openntpd. Außerdem hat die noch Firmware .49, wo es den chrony noch nicht gab. Wenn ein Eintrag in der Anruflist mal falsch ist, bleibt der so

 

[geiercasi]

Habe mal die Rufliste gelöscht. Komischerweise stimmen die Zeiten nun wieder. Weiter beobachten

war bei mir auch so, bis nach nem reboot. dann hatte ich wieder einen falschen eintrag.

gruß

 

[frank_m24]

Hallo,

nach einem Reboot wird die Zeit ja auch neu gesetzt.

 

[cuma]

Changeset 3044 brachte bei mir keine Änderung:

Log:

chronyd[1974]: chronyd version 1.23 starting
telefon[1676]: set initial telefon time from linux time to 20:00 5.02 2009!
crond[1856]: time disparity of 4786259 minutes detected
chronyd[1974]: Initial txc.tick=10000 txc.freq=0 (0.00000000) txc.offset=0 => hz=100 shift_hz=7
chronyd[1974]: 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
chronyd[1974]: Linux kernel major=2 minor=6 patch=19
chronyd[1974]: calculated_freq_scale=0.99902439 freq_scale=0.99902439
[COLOR="Red"]chronyd[1974]: Could not open /dev/rtc, No such device or address[/COLOR]
chronyd[1974]: Real time clock not supported on this operating system
chronyd[1974]: System's initial offset : 0.002874 seconds slow of true (slew)
chronyd[1974]: Could not send to 62.149.0.30 : Bad file descriptor
chronyd[1974]: Could not send to 0.0.0.2 : Bad file descriptor
chronyd[1974]: Could not send to 62.149.0.30 : Bad file descriptor
chronyd[1974]: Could not send to 0.0.0.2 : Bad file descriptor
chronyd[1974]: Could not send to 62.149.0.30 : Bad file descriptor
chronyd[1974]: Could not send to 0.0.0.2 : Bad file descriptor

$ l /dev/|grep rtc
crwxrwxrwx    1 root     root     254,   0 Jan  1  2000 rtc
crwxrwxrwx    1 root     root     254,   1 Jan  1  2000 rtc1

Und was mir noch auffiel beim Shutdown:

kernel: [avm-rtc]: avm_rtc_release_external_interrupt(97994C00)

bzw

lsmod|grep rtc
rtc_avm                 6228  1 pcmlink
rtc_core                7083  1 rtc_avm
rtc_lib                 2712  2 rtc_avm,rtc_core

 

[zirkon]

war bei mir auch so, bis nach nem reboot. dann hatte ich wieder einen falschen eintrag.

Die Uhrzeit wurde ja nicht via Telefon gesetzt. Nach dem Löschen der Anrufliste waren die Einträge wieder mit der richtigen Uhrzeit hinterlegt. Habe inzwischen auch mehrmals die Box neugestartet und bisher stimmt alles.

 

[cando]

AVM wird doch die Zeit nicht nach der Telefonliste stellen?

und sich sagen, wenn ich schon kein Sync mit ntp bekomme (1.1.1900), dann stelle ich die Uhr auf die letzte bekannte Zeit (letzter Eintrag in Telefonliste), damit wenigstens ein ankommender neuer Anruf am oberen Ende im Log erscheint, in der Hoffnung, dass irgendwann bei abgehenden Calls ISDN die Zeit richtig stellt (unter der Annahme, der Log hat a: die richtige Zeit und b: liegt immer in der Vergangenheit).

Vermute mal ->

if time < max(telefonliste) then time = max(telefonliste)

Wenn natürlich durch einen Bug der letzte Eintrag in der Liste im Jahr 2018 ist, geht die Logik in die Hose...

:-Ö

 

[cuma]

Meine Telefonliste wird durch Jfritz immer geleert, scheidet also als Uhrsache aus :-]

 

[zirkon]

Mit der neuesten Phone-Labor tritt das Problem nun wieder auf. Komische Sache, zumal man seine Statistiken in die Tonne stampfen kann

 

[wollet42]

ich glaub das Problem war nie geloest (zumindest bei mir nicht)

 

[zirkon]

Habe das Problem auch mal AVM gemeldet, da ich nicht einmal via Telefon oder Konsole (date) die Uhrzeit ändern konnte. Habe jetzt nach etwas hin und her die Bestätigung erhalten, dass sie das gleiche Problem haben und es an die Entwickler weitergeleitet wurde.

 

[cuma]

Wie kann man denn den Counter sicher? Ich hab zwar mit "cat /var/flash/stat.cfg > sonstwo" eine Sicherung, nur einspielen kann ich diese nicht, die Werte werden nciht angenommen

 

[markuschen]

Ich habe in der /var/flash/ar7.cfg den ntp-Server mal geändert, z.B. auf ptbtime1.ptb.de . Bis jetzt (3 Neustarts) erstmal keine Probleme mehr. Ich werde es weiter beobachten.

 

[zirkon]

Bei mir steht nur ein Eintrag mit einer Liste der Zeitserver:

ntpclient {
        server_list = "0.europe.pool.ntp.org";
}

Hast du diesen Eintrag geändert?

 

[markuschen]

Richtig, genau diesen Eintrag. ptbtime1.ptb.de ist der NTP-Server der Physikalisch-Technischen Bundesanstalt, der hat ne feste IP und ist immer erreichbar. Bei ntp.org gibts per Zufall immer einen anderen NTP-Server (Stichwort: Round Robin DNS), evtl. kommt der chronyd damit nicht ganz klar. Vlt. ist es aber auch nur Zufall, ich werde es mal über einen längeren Zeitraum beobachten.

 

[zirkon]

Wo lag denn bei dir der Hase im Pfeffer begraben? Die Systemzeit stimmt nämlich bei mir, nur die Anrufliste und Nachrichten auf dem AB werden in der Zukunft gespeichert...

 

[frank_m24]

Hallo,

möglicherweise ist es eine Art Race-Condition.
Offensichtlich holt sich die Box die Zeit per NTP. Und der Telefon-Daemon synct sich dann beim Booten gegen die System-Zeit. Jetzt können drei Fälle eintreten:

• NTP ist flott fertig, der Telefon-Daemon bekommt die korrekte Zeit, auch die System-Zeit stimmt
• NTP braucht etwas länger. Der Zeit-Sync des Telefon-Daemons findet zu früh stat. Zwar stimmt am Ende die System-Zeit, aber die Zeiten in den Ruflisten etc. stimmen nicht
• NTP scheitert komplett (z.B. Timeout). Sowohl Systemzeit als auch Telefon-Zeit sind falsch

Das würde zum einen erklären, warum das Problem nur sporadisch und in verschiedenen Ausprägungen auftritt. Zum anderen würde es erklären, warum der Wechsel auf einen anderen (zuverlässigeren und schnelleren) Server Abhilfe schafft.

 

[cuma]

Ist halt nur komisch, dass dann bei einem Fehlschlag ein Jahr in der Zukunft genommen wird. Und der Tag & Monat stimmen meist bei mir.
Ich lasse meine Box jetzt immer neu booten, wenn was nicht passt

[ "`date|sed 's/^.* //'`" -gt 2015 ] && reboot

Ich finde es aber auch unüblich, dass AVM in der "server_list" nur genau einen Server "0.europe.pool.ntp.org" angibt, ein Pool wie "de.pool.ntp.org" sollte da doch wesentlich besser sein.
Im Log sieht man auch. dass 3x der gleich Server befragt wird, ich denke dass da ein Fehler in der Config unterlaufen ist und probier's mal mit dem Pool.


Funktioniert (soweit) gut:

chronyc -n
password avm
210 Number of sources = 4
MS Name/IP address           Stratum Poll LastRx Last sample
============================================================================
^~ 78.47.136.197                 2   10    535    -38ms[  -38ms] +/-   49ms
^~ 78.46.51.71                   2   10    537    -35ms[  -35ms] +/-   48ms
^? 78.47.43.180                  2   10    535    -38ms[  -38ms] +/-   67ms
^~ 85.214.18.161                 2   10    535    -32ms[  -32ms] +/-   46ms
quit

 

[markuschen]

Ich habe folgendes festgestellt:

1. chronyd versucht sich per NTP von irgendeinem Server aus dem "0.europe.pool.ntp.org"-Pool die Zeit zu holen, dies klappt zumindest bei meiner 7270 so gut wie nie - zumindest nicht in der Startphase der Box (noch nicht online ?). Die falsche Zeit ist überall zu sehen, in der Anrufliste bei eingehenden ISDN- und ein- und ausgehenden VoIP-Gesprächen. Auch eine date unter Telnet beweist dies.
2. Wenn ich ein ausgehendes ISDN-Telefonat führe (z.B. mal kurz die T-Net Box unter 0800 3302424 anrufen und rangehen lassen!) holt sich der telefond die richtige Zeit von der Vermittlungsstelle und setzt diese Zeit auch unter Linux (wieder mit date bei Telnet geprüft). Alle Telefonate ab diesem Zeitpunkt erscheinen in der Anrufliste mit dem richtigen Datum.

Vlt. hilft dies dem einen oder anderen weiter.

PS: Im Moment habe ich mit ptbtime1.ptb.de immernoch keine Probleme mehr.

Grüße von markuschen