Jahr 2017 oder 2035 in Fritzbox?

frank_m24 · 5 Feb 2009

Hallo,

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

zirkon · 5 Feb 2009

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

cuma · 5 Feb 2009

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 · 5 Feb 2009

zirkon schrieb:
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 · 5 Feb 2009

Hallo,

nach einem Reboot wird die Zeit ja auch neu gesetzt.

cuma · 5 Feb 2009

Changeset 3044 brachte bei mir keine Änderung:

Log:

Code:

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

Code:

$ 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:

Code:

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

bzw

Code:

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

zirkon · 6 Feb 2009

geiercasi schrieb:
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 · 6 Feb 2009

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 ->

Code:

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 · 6 Feb 2009

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

zirkon · 13 Feb 2009

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

wollet42 · 13 Feb 2009

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

zirkon · 13 Feb 2009

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 · 13 Feb 2009

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 · 24 Feb 2009

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 · 24 Feb 2009

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

Code:

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

Hast du diesen Eintrag geändert?

markuschen · 24 Feb 2009

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 · 24 Feb 2009

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 · 25 Feb 2009

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 · 25 Feb 2009

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

Code:

[ "`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:

Code:

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 · 25 Feb 2009

Ich habe folgendes festgestellt:

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.
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

Jahr 2017 oder 2035 in Fritzbox?

IPPF-Urgestein

Aktives Mitglied

Aktives Mitglied

Mitglied

IPPF-Urgestein

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Aktives Mitglied

Neuer User

Aktives Mitglied

Aktives Mitglied

Mitglied

Aktives Mitglied

Mitglied

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Mitglied

Statistik des Forums