Jahr 2017 oder 2035 in Fritzbox?

[hoppel118]

Seitdem ich die deutschen Zeitserver von "de.pool.ntp.org" in der ar7.cfg nutze, habe ich keine Probleme mehr, original waren ja die europäischen in Verwendung...

Ich glaub alle hier die auf "de.pool.ntp.org" umgestellt haben sind zufrieden!

Greetz

Hoppel

 

[Silent-Tears]

Ich hatte das Problem erneut, was anscheinend wohl daran liegt, wenn zu wenige Server in der ar7.cfg stehen.

Das Startscript liest die dort genannten Server aus. Einer alleine (ptbtime1.ptb.de hatte ich stehen) reicht nicht, und der chronyd hat sich sofort wieder beendet.
Nachdem ich den Pool wieder eingetragen hab, hatte ich wieder mehrfach 2013 als Jahr, somit hab mich mir das zwischendurch mal angeguckt.
Jetzt hab ich mehrere (sind aktuell 3) Fixe Server (kein Pool) in der ar7.cfg eingetragen, und es läuft stabil, und auch die Uhrzeit wird nach mehrfachen Reboots vernünftig gesetzt.

 

[RalfFriedl]

Mit welchem Server/Pool gibt es denn Probleme? Es sollte sich doch feststellen lassen, ob/welcher Server da eine falsche Zeit zurück gibt.

 

[Silent-Tears]

Per Default steht es auf pool.ntp.org, glaube ich. de.pool.ntp.org brachte bei mir auch Fehler, und mit ausschliesslich einem fixen Server in der ar7.cfg ging es nicht ,da die Zeit zwar initial bei booten gesetzt wurde, aber dann der chronyd mit einem segfault beendet wurde.

 

[RalfFriedl]

Ich habe mal 100 Anfragen an pool.ntp.org gemacht, da kamen Zeitabweichungen bis maximal 0,013s heraus. Es scheint also ein Problem auf der Box sein.

 

[cuma]

Ich denke mal, dass die Internetverbindugn bzw Namensauflösung nicht schnell genug geschieht. Bei Erfolg sehe ich nur 3x die IP 0.0.0.0, sonst 6x im Syslog

 

[Silent-Tears]

Impliziert, dass man mit ein wenig rc-trickserei (rc-level nach hinten schieben) ja schon gewonnen hätte? (Und ist das überhaupt möglich bei den AVM-Scripten? Sonst wäre evtl eine eingebaute Pause von X Sekunden schon ausreichend?

 

[cuma]

Könnte sein, ist halt nur eine Vermutung

 

[hoppel118]

Hat die "rc-trickserei" mittlerweile mal jemand getestet? Ich hab mir gestern das aktuelle SVN (3257) gezogen und habe nun mit dem normalen de-pool auch Probleme. Aber erst seitdem ich das neue Image gebaut habe, vorher war alles gut.

Aktuell siehts bei mir so aus, das funktioniert zumindest gerade:

ntpclient {
        server_list = "0.de.pool.ntp.org,1.de.pool.ntp.org,2.de.pool.ntp.org,3.de.pool.ntp.org";
}

 

[Silent-Tears]

Ich habIPs eingetragen. Funktioniert seit geraumer Weile zuverlässig

 

[hoppel118]

Ok, das wird dann mein nächster Versuch! Hab aber vorhin 5mal neu gestartet und es hat 5mal geklappt. Also bleibts erstmal so, es sei denn jemand hat sich mit dem rc-gefriggel beschäftigt...

 

[itzy]

*schieb*

Bei mir funktionierts mit der Liste von hoppel118 problemlos.

Wenn es ein Problem mit der Namensauflösung ist, hilft vielleicht ein Eintrag in der hosts. Leider weiss ich nicht ob das Linux auf der FBox eine multi-ip hosts akzeptiert.

 

[SaschaBr]

Nachdem ich von dem Problem der falsch gesetzten Systemzeit bisher verschont geblieben bin, hats mich heute dann doch erwischt:

Die Geschichte:
Nachdem meine Frau es heute irgendwie geschafft hatte, den Drucker am USB-Port der Box total durcheinander zu bringen, habe ich die Fritz-Box und den Drucker mal für zwei bis drei Minuten stromlos gemacht. Nach dem Starten habe ich mich dann gewundert, dass die RRD-Stats-Daten nicht mehr verfügbar waren. OK, dachte ich mir, hattest schon mal! Also nochmal ein Neustart, aber wieder nix. Danach habe ich mir gedacht: Scheiß was drauf, sind die Daten halt weg.
Jetzt grade wunder ich mich, warum die Nachtschaltung das W-Lan nicht deaktiviert hat, und schaue im Ereigniss-Log der Box nach: 17.11.2017-20:12!? Auch weitere Neustarts brachten keine Besserung.

Die Lösung:
Ich habe die von hoppel118 vorgeschlagene NTP-Server auch in meine ar7.cfg eingetragen, und mit dem nächsten Neustart war wieder alles gut.

EDIT am 13.06.09:
Die Uhrzeit der Box wurde durch die hoppel118-Liste zwar gesetzt, jedoch blieb die Uhrzeit der Anrufliste falsch. Im Syslog fehlte auch definitiv der Eintrag "set initial telefon time from linux time to ...". Erst nach erneuter Änderung des ntp-Servers in der ar7.cfg stimmen wieder alle Zeiten:

ntpclient {
        server_list = "de.pool.ntp.org";
}

 

[rgrr]

Hallo zusammen,

heute hat mich das Problem auch erwischt!

Aber so richtig zufrieden bin ich mit den ar7.cfg-Erklärungen nicht. Paar Fragen/Bemerkungen:
- bei mir gibt es in keiner ar7.cfg einen Eintrag mit *ntp*
- in /etc/init.d/rc.chrony steht 0.europe.pool.ntp.org
- im Log wird die Uhrzeit korrekt angezeigt, dann mit dem Offset:

Jan  1 01:00:46 fritz daemon.info chronyd[1213]: calculated_freq_scale=0.99902439 freq_scale=0.99902439
Jun 19 21:44:54 fritz daemon.info chronyd[1213]: System's initial offset : 298755846.488822 seconds slow of true (step)
Dec  7 16:29:01 fritz user.err telefon[945]: set initial telefon time from linux time to 16:29 7.12 2018!
Dec  7 16:29:02 fritz daemon.warn chronyd[1213]: Could not send to 213.129.242.93 : Bad file descriptor
Dec  7 16:29:03 fritz daemon.warn chronyd[1213]: Could not send to 213.129.242.93 : Bad file descriptor
Dec  7 16:29:04 fritz daemon.warn chronyd[1213]: Could not send to 213.129.242.93 : Bad file descriptor
Dec  7 16:29:43 fritz auth.info login[1288]: root login on 'pts/0'
Dec  7 16:29:59 fritz daemon.info chronyd[1213]: Trimming RTC, error = -1544200116.043 seconds
Dec  7 16:33:54 fritz daemon.info chronyd[1213]: Source 78.46.78.103 offline

- ich hatte bisher keine Probleme. Was ich gestern gemacht hatte war, dass
ich eine neue freetz-Version aufgespielt hatte und diese USB-Probleme (scheinbar)
verursachte, habe ich wieder einen Downgrade auf die vorherige Variante
gemacht. U.U. habe ich mir da Unstimmigkeiten in meiner Konfiguration
eingehandelt

Jetzt kommt noch ein ABER: das äusserst Interessante an der Angelegenheit ist, dass auf meinem DECT-Telefon, welches über die Analog-Schnittstelle (FON1) betrieben wird, als Zeitstempel ebenfalls der 6.12. bei einem Anruf angezeigt wurde. Wie kann denn das sein? Ich habe schliesslich die Uhrzeit in dem Telefon korrekt eingegeben, wird auch im Display entsprechend angezeigt. Oder wird per CLIP o.ä. die Uhrzeit eines Anrufs übergeben?

Hardy

 

[rgrr]

...Hardy

Auch wenn ich ungerne Followups auf Eigenes mache...

Vielleicht bin ich auch in einem ganz anderen 'Film'/Thread. Ich mache folgendes:

/var/tmp # date -s "2009-06-19 22:43:00"
Fri Jun 19 22:43:00 CEST 2009
/var/tmp # date
Fri Dec  7 17:28:03 CET 2018
/var/tmp #

Was ist denn das? Ist das ein Berechtigungsproblem?

Hardy

 

[hermann72pb]

... Oder wird per CLIP o.ä. die Uhrzeit eines Anrufs übergeben?

Ja, richtig erkannt. Und die meisten neueren Telefone werden dann gleich auf diese Zeit "synchronisiert". Die Idee kommt -soweit ich weiß- aus der ISDN-Welt, wo es Gang und Gebe war. Allerdings sollte es normalerweise durch den Telefon-Provider angeregt werden. In diesem Fall hängt sich die Box dazwischen.

Zu den ar7.cfg und sonstigen configs. Es wäre hilfreich ab und zu Sicherungen zu machen und Dateien vor und nach miteinander zu vergleichen. Bei bzw. nach manchen Updates finden diverse Konvertierungen statt, sodass die Dateien per Downgrade nicht zwangsläufig rückgängig gemacht werden können.

Ansonsten benutze bitte "edit"-Funktion, wenn du was nacheinander schreibst.

MfG

 

[rgrr]

Ja, richtig erkannt. Und die meisten neueren Telefone werden dann gleich auf diese Zeit "synchronisiert".

Das lustige ist, dass das Telefon selbst nicht synchronisiert, aber diese falsche Zeit in der Anrufliste und bei der AB-Zeit entsprechend verwendet wird. Nicht ganz konsistent...

Zu den ar7.cfg und sonstigen configs. Es wäre hilfreich ab und zu Sicherungen zu machen und Dateien vor und nach miteinander zu vergleichen.

Danke für den Hinweis. Ich werde mal meine letzte Sicherung mit dem aktuellen Zustand vergleichen. In der gesicherten ar7.cfg steht auch tatsächlich was vom ntpclient drinnen.

Ansonsten benutze bitte "edit"-Funktion, wenn du was nacheinander schreibst.

Naja, das kann man sehen, wie man will. Im USENET seinerseits kam das auch vor, dass man sich selbst zitieren musste. Editieren hat nämlich den Nachteil, dass der aktualisierte Beitrag nicht durchgelesen wird (meine Meinung).

Aber egal, denn ein Punkt bleibt offen: warum klappt das manuelle Setzen der Zeit nicht? Greift da chronyd ein, oder gibt es da Berechtigungsprobleme?

Hardy

 

[Silent-Tears]

Naja, das kann man sehen, wie man will. Im USENET seinerseits kam das auch vor, dass man sich selbst zitieren musste. Editieren hat nämlich den Nachteil, dass der aktualisierte Beitrag nicht durchgelesen wird (meine Meinung).

Das Usenet interessiert hier nicht, genausowenig wie das Usenet wohl bei Usern die Netiquette des IPPF berücksichtigt.

 

[pengu]

Und mal wieder hatte ich das hier angesprochene Problem,wobei ich diesmal 2018 zu lesen bekam *g*

Einmal auf der Box geschaut was da so last macht und schnell war
chronyd als Übeltäter ausgemacht.
Nach den üblichen Bereinigungen im Telefonbuch und Neustart der 7270 (Basis) wird nun alles wieder korrekt angezeigt.

Wobei entgegen der Anzeige ich aus dem Syslog entnehmen konnte, dass "telefon" da nochwass gemacht hat.
Leider hab ichs nicht mehr da und momentan stimmts auch wieder.

 

[rgrr]

Einmal auf der Box geschaut was da so last macht und schnell war
chronyd als Übeltäter ausgemacht.
Nach den üblichen Bereinigungen im Telefonbuch und Neustart der 7270 (Basis) wird nun alles wieder korrekt angezeigt.

Hallo pengu,

was sind diese üblichen Bereinigungen etc? Könntest Du mir auch den Gefallen tun, und auf Deiner Box testweise händisch die Uhrzeit setzen. Ich bin mir nämlich nicht sicher, ob ich (zwei weiter oben) ein individuelles oder systematisches Problem habe.

Danke

Hardy


PS: aktueller Zustand meiner Box:

Log:
...
Jun 22 00:28:04 fritz user.err telefon[945]: set linux time to Mon Jun 22 00:28:04 2009
Jun 22 04:39:24 fritz user.err telefon[945]: set linux time to Mon Jun 22 04:39:24 2009

telnet:
...
ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
/var/mod/root # date
Sun Dec  9 23:48:01 CET 2018

Wobei entgegen der Anzeige ich aus dem Syslog entnehmen konnte, dass "telefon" da nochwass gemacht hat.
Leider hab ichs nicht mehr da und momentan stimmts auch wieder.[/QUOTE]