Zeitsynchronisierung

[rk97]

Hallo!
Ich versuche gerade herauszufinden, wie das FritzOS mit meinen Angaben zu Servern und denen vom DHCP des ACS umgeht. Dabei versuche ich dem FritzOS beizubringen, daß es meinen NTP-Server im direkt angeschlossenen Netz nimmt. Das ist der handelsübliche NTPd unter dem aktuellen Raspbian Stretch. Weitere Randbedingung: Fritzbox 7412 mit FritzOS 6.83 ohne Branding, nach Werksreset in Betrieb genommen mit dem scheinbar abgeschalteten TR-069 (es hat funktioniert ) bereits vor der ersten Kontaktaufnahme des FritzOS mit dem ACS (von 1&1 bzw. Telekom).

Eigener DNS-Server ebenso unter Raspbian beschränkt auf IPv4. Dieser ist als DNS-Server in der Fritzbox eingetragen, und den nimmt das FritzOS für die Namensauflösung vom NTP-Server, aber für keine andere Namensauflösung. Beobachtung: ich sehe die Anfragen zur Namensauflösungen mit folgenden Zeitabständen: 5sec, 10sec, 20sec, 85sec und wieder von vorne. Unter System/Ereignisse wird mir erzählt: "Zeitserver ntp.<tld> antwortet nicht. [<N> Meldungen seit <Datum, Uhrzeit>]". D.h. die Fritzbox hat nach dem Einschalten eine einigermaßen korrekte Uhrzeit erhalten, benutzt diese allerdings ausschließlich für die Protokollierung der "Ereignisse". An anderen Stellen wird die Zeit ab 1.1.1970 gezählt, so unter Überblick oder im Telefonieprotokoll. Bemerkung: mein NTP-Server funktioniert mit diversen Betriebssystemen als Client nicht nur aus dem direkt angeschlossenen LAN, sondern auch aus anderen Subnetzen. D.h. den halte ich für unauffällig. Für den DNS-Server gilt dasselbe

Kurz: FritzOS versteht meinen NTP-Server derzeit gar nicht, beim vorangegangenen Versuch haben sie sich unvollständig verstanden, die Fritzbox ging 2h nach. Hat schon mal jemand in dieser Ecke geforscht und Auffälligkeiten entdeckt?

TIA

 

[Micha0815]

die Fritzbox ging 2h nach

Dies klingt nach falscher "Timezone". Diese steht üblicherweise auf "auto" und sollte manuell ggfs. angepasst werden. Kannst Du ja in der *.export oder support-Datei nachlesen.
LG
P.S.: 2h könnten GMT +0 vs. GMST +1 sein?

 

[sf3978]

...daß es meinen NTP-Server im direkt angeschlossenen Netz nimmt. Das ist der handelsübliche NTPd unter dem aktuellen Raspbian Stretch.

Wie sind auf deinem PI, die Ausgaben von:

diff -s /etc/localtime /usr/share/zoneinfo/`cat /etc/timezone`
date && rdate -4npu ptbtime2.ptb.de
ntpq -4np

und aus deinem (W)LAN, die Ausgabe von:

rdate -4npu <interne-IP4-Adresse-PI>

(oder gleichwertig)?

 

[koyaanisqatsi]

Moins


DNS für einen lokalen NTP Server ist imo keine gute Idee.
( Abfragen werden bestimmt ans Internet gestellt )

Erstelle mal die "Erweiterte Supportdaten", lad die mal ( Webbrowser/Texteditor ) und such alles nach "chrony" ab.

Als Klient gibt es auch noch ein Fallback, falls der Selbsteingetragene nicht gefunden wird oder antwortet...

ntpclient {
        server_list = "times.tubit.tu-berlin.de";
        fallback_server = "2.europe.pool.ntp.org";
        chrony_enabled = yes;
}

( aus einer 7590 mit 6.98 Inhaus )

 

[eisbaerin]

Erstelle mal die "Erweiterte Supportdaten"

Das steht in der normalen Sicherungsdatei auch in der ar7.cfg.

 

[koyaanisqatsi]

Das was ich im

 gepostet habe ist nur ein klitzekleiner Treffer aus den Supportdaten.

Und, da haste Recht, zufällig auch in der Sicherungsdatei, aber hoffentlich nicht die von vor 2 Jahren

 

[rk97]

Dies klingt nach falscher "Timezone". Diese steht üblicherweise auf "auto" und sollte manuell ggfs. angepasst werden. Kannst Du ja in der *.export oder support-Datei nachlesen.

Ich gehe sogar davon aus, daß die Fritzbox in diesem Moment gar keine Zeitzone hatte und daher auf GMT "sprang". Das könnte ein Hinweis sein, daß ich TR-069 erfolgreich ausgebremst habe, wenn das vom ACS geliefert werden würde.

Wie sind auf deinem PI, die Ausgaben von:

diff -s /etc/localtime /usr/share/zoneinfo/`cat /etc/timezone`

identisch: Europe/Berlin
Mit den ganzen anderen Rechnern funktioniert NTP einwandfrei, d.h. andere Raspbians, Ubuntu, Windows und MacOS.
"rdate" habe ich nicht installiert, und

ntpq -4np

zeigt mir die eingetragenen Pool-Adressen sowie je nach Zeitpunkt der Anfrage unterschiedliche NTP-Server an. Der nächstgelegene hat den '*' davor. Ich habe hinter diesem ersten NTP-Server in einem anderen Subnetz einen weiteren Raspi, der auf diesen ersten verweist. Da sehe ich die Kaskade sehr schön. Mit "timedatectl" verfolge ich das das genauso:

      Local time: Sa 2018-07-14 10:49:36 CEST
  Universal time: Sa 2018-07-14 08:49:36 UTC
        RTC time: Sa 2018-07-14 08:49:36
       Time zone: Europe/Berlin (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

### Zusammenführung Doppelpost by stoney ###

DNS für einen lokalen NTP Server ist imo keine gute Idee.
( Abfragen werden bestimmt ans Internet gestellt )

Die Anfrage geht an meinen lokalen NTP-Server. Mit der DNS-Anfrage wollte ich sehen, was passiert. Ich hatte statt der symbolischen Adresse auch eine IPv4-Adresse drin. Die Zeitsynchronisation ging trotzdem nicht. Aber ...

Erstelle mal die "Erweiterte Supportdaten", lad die mal ( Webbrowser/Texteditor ) und such alles nach "chrony" ab.

... das ist eine gute Idee:

ntpclient {
        server_list = "ntp.r.lan";
        chrony_enabled = no;
}

Warum nur schaltet FritzOS den ab? Ich kann das im Web-Interface nicht beeinflussen.

 

[PeterPawn]

Warum nur schaltet FritzOS den ab? Ich kann das im Web-Interface nicht beeinflussen.

Das ist (bzw. richtiger wäre "war") ein schon sehr alter Fehler im Web-Interface der Box, wenn eine FRITZ!Box nicht als DHCP-Server arbeitete ... dann wurde im GUI auch die Eingabemöglichkeit für den Zeitserver deaktiviert.

Das ist aber seit Version 06.9x schon behoben und auch zuvor war das eher ein "Schönheitsfehler", weil der intern verwendete "chronyc" eine bereits getroffene Einstellung weiterhin nutzte - man konnte also den DHCP-Server aktivieren, die NTP-Einstellung ändern und (nach dem Speichern der geänderten Einstellung) den DHCP-Server auch wieder deaktivieren - die Uhrzeit wurde trotzdem vom NTP-Server geholt.

Was hier konkret falsch läuft, weiß ich auch nicht ... aber das "rdate"-Applet der BusyBox verwendet ohnehin keinen NTP-Server (und ist m.W. in der AVM-BusyBox auch gar nicht enthalten), sondern braucht einen "daytime"-Service auf dem Server, der seinerseits auch wieder keinen NTP-Server benötigt, sondern in den meisten "Super-Daemons" (inetd, xinetd) bzw. im System-IP-Stack bereits implementiert ist (wie "echo" und andere "Basisdienste").

Ansonsten zählt die Box die Uhrzeit generell als "epoch time" und die startet nun mal bei jedem Booten der Box neu, weil sie keine eigene RTC hat. Bis sie jetzt eine gültige Uhrzeit erhält, speichert sie alle ihre eigenen Meldungen (ob das bei Telefonaten auch so ist, weiß ich gerade nicht - kann man aber leicht selbst testen) mit einem Offset zum Beginn des Protokollierens und wenn sie dann eine gültige Zeit gesetzt hat, errechnet sie aus der aktuellen Zeit und der seit dem Beginn des Protokollierens verstrichenen Zeit den "Startzeitpunkt" für das Protokoll und speichert diesen für künftige Berechnungen.

Durch dieses Verfahren kann es auch mal zu Rundungsfehlern beim Berechnen der Uhrzeit für einen konkreten Eintrag im Event-Log der Box kommen ... das äußert sich dann darin, daß die Sekunden einer einzelnen Meldung auch mal um eins differieren können (wenn die Summe aus Startzeitpunkt + Time-Offset mal auf- und mal abgerundet wird), wenn man dasselbe Protokoll mehrfach abruft.

In den 06.8x-Versionen von AVM ist m.E. noch ein zusätzlicher Fehler enthalten ... wenn der eingetragene NTP-Server nicht über die WAN-Verbindung erreichbar ist, werden die Zeitangaben aus dem bzw. für den "multid / kdsld" nach dem Setzen der aktuellen Zeit nicht korrigiert - meine 6490 (mit 06.83) erklärt mir jedenfalls nach dem Booten auch tapfer, daß die Internetverbindung (trotz gültiger Uhrzeit im Event-Log) seit dem 01.01.2000 bestünde (da läuft der relevante Teil auf dem ATOM-Core und der zählt ab dem Jahr 2000 beim Booten) und daran ändert sich auch nichts (jedenfalls nicht in einem Rahmen, der über die seit dem Booten verstrichene Zeit hinausginge), wenn ich "Neu verbinden" lasse. Die 7412 habe ich gerade nicht zur Hand (bzw. nicht mit der richtigen Version), um die Vermutung bei diesem Modell auch noch einmal zu überprüfen ...

Ich würde hier aber eher mit einer anderen FRITZ!OS-Version (und wenn möglich, mit einem anderen Modell, für das es eine 06.9x bereits gibt, wo dann das Eintragen im GUI auch ohne aktivierten DHCP-Server möglich sein sollte) noch einmal testen, bevor ich am NTP-Server schraube ... wobei auch ein Mitschnitt ja deutlich zeigt, ob/daß sich die Box die Zeit beim NTP-Server holt.

Da ich in meinen Images nichts am NTP-Client ändern will (der ist mir zu sehr in den "multid" verwoben), lasse ich (mit dem "rdate"-Applet der BusyBox und einem kleinen RC-Skript) die Zeit beim Booten setzen, sobald das Netzwerk initialisiert wurde (aber eben nicht über NTP):

root@FB7490:~ $ cat /etc/init.d/S50-rdate
#! /bin/false
# avoid to be called without explicit shell invocation
# vim: set syntax=sh tabstop=2 shiftwidth=2 highlight=on
#################################################################################
#                                                                               #
# S50-rdate                                                                     #
#                                                                               #
# try to set our RTC from a local network source, this may lead to a faster     #
# boot process, because any process waiting for a valid local time may continue #
# to run after this script sets the correct date and time                       #
#                                                                               #
#################################################################################
#                                                                               #
# our configuration                                                             #
#                                                                               #
#################################################################################
CFG=$YF_CONFIG_CFGDIR/rdate.conf
#################################################################################
#                                                                               #
# try to find our configuration file, the YF_CONFIG values are set by caller    #
#                                                                               #
#################################################################################
if [ -f $CFG ]; then
        if [ -s $CFG ]; then
                SERVER=$(sed -n -e "s|^SERVER=\(.*\)\$|\1|p" $CFG)
                if [ ${#SERVER} -gt 0 ]; then
                        SERVER="${SERVER//\"/}"
                fi
                /bin/busybox logger "Setting date/time from server $SERVER"
                /bin/busybox rdate $SERVER
        fi
fi
#################################################################################
#                                                                               #
# end of script                                                                 #
#                                                                               #
#################################################################################
root@FB7490:~ $

 

[rk97]

Das ist (bzw. richtiger wäre "war") ein schon sehr alter Fehler im Web-Interface der Box,

Danke für Deine sehr ausführliche und erklärende Antwort. Ich erkenne, daß ich hier mit mehreren Fehlern und falschen Annahmen von mir kämpf(t)e.

Web-Interface und schlechte Umsetzung auf die tatsächliche Konfiguration, Daytime-Service (ich dachte, daß der mittlerweile ausgestorben sei), NTP nur richtig über WAN, ... Da hatte ich keine Chance.

Ansonsten zählt die Box die Uhrzeit generell als "epoch time" und die startet nun mal bei jedem Booten der Box neu, weil sie keine eigene RTC hat.

Wenn ich das letzte Nacht richtig beobachtet habe, dann beginnt die Uhrzeit nach jedem Einschalten am 1.1.1970 1:00 Uhr (FritzOS 6.83 auf der 7412). Über einen Neustart scheint die Zeit irgendwo erhalten zu bleiben, wenn vielleicht auch mit Verlust der Boot-Zeit, weil ein Zeitstempel aus dem Dateisystem genommen wird (macht Raspbian so, bis NTP oder der RTC-Treiber eine gültige Zeit liefert).

Bis sie jetzt eine gültige Uhrzeit erhält, speichert sie alle ihre eigenen Meldungen (ob das bei Telefonaten auch so ist, weiß ich gerade nicht - kann man aber leicht selbst testen) mit einem Offset zum Beginn des Protokollierens und wenn sie dann eine gültige Zeit gesetzt hat, errechnet sie aus der aktuellen Zeit und der seit dem Beginn des Protokollierens verstrichenen Zeit den "Startzeitpunkt" für das Protokoll und speichert diesen für künftige Berechnungen.

Das entspricht meiner Beobachtung. Sie scheint die Sekunden seit Systemstart zu zählen. Wenn TR-069 läuft, scheint FritzOS die Zeit synchronisert zu haben, bis die ersten relevanten Aktionen anstehen.

Ich würde hier aber eher mit einer anderen FRITZ!OS-Version (und wenn möglich, mit einem anderen Modell, für das es eine 06.9x bereits gibt, wo dann das Eintragen im GUI auch ohne aktivierten DHCP-Server möglich sein sollte) noch einmal testen, bevor ich am NTP-Server schraube ... wobei auch ein Mitschnitt ja deutlich zeigt, ob/daß sich die Box die Zeit beim NTP-Server holt.

Wireshark oder den NTP-Server im Debug-Modus wären meine nächsten Schritte geworden.

Da ich in meinen Images [...]

Gibt's hier irgendwo eine Anleitung für Anfänger wie mich, wo steht, wie man wieder an so was wie das frühere Telnet kommt? Ich habe seit gestern meine zweite 7412 zum Experimentieren. D.h. ich werde nachher erstmal die magischen vier Stifte einlöten, um dann hoffentlich eine serielle Schnittstelle mit Shell vorzufinden. Ich hatte gestern beim Booten das Oszi kurz an den TxD-Pin gehalten: es wackelte Andere Wege sind trotzdem willkommen.

Meine andere Idee war die export-Datei zu ändern und rückzulesen. Geht nur nicht, weil irgendwo eine magische Prüfsumme gebildet wird. Gibt's dazu irgendwo einen Hinweis, wie man diese Prüfsumme generieren kann und wo die steht?

Mein besonderes Interesse gilt hier eigentlich dem TR-069. Bisher schrieb das FritzOS (6.83) in die export-Datei unter tr069cfg und dort hinter LastSuccessfulContact den Zeitpunkt der letzten Anmeldung. Jetzt steht dort unverändert der 1.1.1970 1:00Uhr.

 

[PeterPawn]

Nicht böse sein ... aber die "nachgefragten Informationen" stehen hier tatsächlich im IPPF - halt in anderen Threads.

Für das Starten einer Shell auf einer 7412 gibt es eine komplette Lösung für eine "Shell-in-a-Box"-Konsole (SIAB), die auch ohne Lötarbeiten auskommt und auch das Berechnen der Prüfsumme für eine Export-Datei (oder das "Entschlüsseln" einer solchen) ist (einigermaßen umfassend) dokumentiert.

Dir jetzt Deine Frage(n) noch einmal zu beantworten, würde meinen eigenen Überzeugungen zuwiderlaufen und daher wird es von mir (neben dem Hinweis in meiner Signatur - wobei i.d.R. von dort auch wieder Links auf die IPPF-Threads führen, wenn man diese nicht direkt durch die eigene Suche findet) da keine direkten Links auf solche Quellen geben. Einen "Dammbruch" kann und will ich mir hier auch nicht leisten ... was sollte man dem Nächsten schreiben, der dieselben Fragen stellt, anstatt einfach selbst erst einmal nach den Antworten zu suchen?

Die Suche (über Suchmaschinen oder sogar über die boardeigene Indizierung hier) ist wirklich nicht schwer und bereits behandelte Themen (erst recht, wenn sie so ausführlich schon durchgekaut wurden) sind eine deutlich andere Sache als Deine ersten Fragen in diesem Thread.

Wobei auch dabei ein paar Schlußfolgerungen in #12 stehen, die deutlich über das hinausgehen, was ich selbst geschrieben habe und die ich (wenn ich sie richtig verstanden habe) für falsch halte ... u.a. die Verknüpfung von TR-069 und dem Setzen irgendeiner Uhrzeit und auch eine Orientierung an irgendwelchen Zeitstempeln im Dateisystem habe ich bei einem Neustart einer FRITZ!Box bisher noch nie beobachten können. Mal ganz abgesehen davon, daß es durchaus Boxen gibt, die gar keinen beschreibbaren Speicher (mit einem "normalen Dateisystem") haben - wobei man das vielleicht auch an Zeitstempeln im TFFS festmachen könnte (macht die Box m.W. aber nicht), auch wenn man keine Ahnung hat, wieviel Zeit seit dem letzten "Stempeln" tatsächlich vergangen ist.

 

[rk97]

Nicht böse sein ... aber die "nachgefragten Informationen" stehen hier tatsächlich im IPPF - halt in anderen Threads.

Ich bin nicht böse Ich hatte solche Suchaktionen hier schon gemacht und nichts oder zu wenig Weitergehendes gefunden.

Signatur habe ich jetzt eingeblendet. Die war bisher aus. Schaunmermal, ob ich das verstehe, was Du auf Github veröffentlichst. Die Eintrittsschwelle ist hoch. Die Suche in anderen Threads hier im Forum ist sehr mühsam. Mehrfach fand ich Informationen unter Überschriften, wo ich sie bei einer gezielten Suche nie erwartet hätte. Und umgekehrt.

Wobei auch dabei ein paar Schlußfolgerungen in #12 stehen, die deutlich über das hinausgehen, was ich selbst geschrieben habe und die ich (wenn ich sie richtig verstanden habe) für falsch halte ... u.a. die Verknüpfung von TR-069 und dem Setzen irgendeiner Uhrzeit und auch eine Orientierung an irgendwelchen Zeitstempeln im Dateisystem habe ich bei einem Neustart einer FRITZ!Box bisher noch nie beobachten können. Mal ganz abgesehen davon, daß es durchaus Boxen gibt, die gar keinen beschreibbaren Speicher (mit einem "normalen Dateisystem") haben - wobei man das vielleicht auch an Zeitstempeln im TFFS festmachen könnte (macht die Box m.W. aber nicht), auch wenn man keine Ahnung hat, wieviel Zeit seit dem letzten "Stempeln" tatsächlich vergangen ist.

Mir sind ein paar Merkwürdigkeiten aufgefallen, seit ich eine 7412 an einem neuen VDSL-Anschluß im Einsatz habe, die meine bisherige 7270 ersetzt hat und dem damit verbundenen Versionssprung in der Firmware. Und das, was jetzt zwischen ACS und meiner(!) Fritzbox abläuft, ist mir etwas suspekt. Das ist neu, genauso neu wie die Technik am anderen Ende meiner Leitung, da die hier im Ort eingebaute Technik in diesem Frühling eingebaut wurde. Auffälligkeiten:
- Telefonnummer wird versucht beim falschen SIP-Server (= falscher Telefon-Provider) anzumelden
- Gespräche gehen nicht über die Rufnummer raus, die konfiguriert ist (mehrfach mehrtageweise), einmal wäre vielleicht erklärbar durch einen Konfigurationsfehler am Anfang
- das Einspielen einer Gerätekonfiguration von einer 7412 auf die nächste läßt etliche Lücken
- DNS- und NTP-Server machen nicht das, was ich erwarte und logisch wäre, siehe oben, allerdings sind genau diese beiden die Grundlagen jeglichen Internet- und somit Telefonverkehrs
- einmaliger Ausfall jeglichen DNS-Verkehrs zwischen meinem Server (dnsmasq auf Raspbian) und allen konfigurierten weit draußen im Internet hinter dem Provider-Netz für rund 30min., 1&1 weiß nichts von einem (temporären) Filter auf Port 53, spontan eingetragener Provider-DNS-Server funktionierte (kein DNSSEC, also unsicher)
- u.a.

Das sind Fehler auf verschiedenen Ebenen, die es vor einigen Monaten noch nicht gab. Ich sortiere ...

 

[PeterPawn]

Ein paar Anhaltspunkte habe ich ja mit den Stichworten im zweiten Absatz in #12 schon geliefert und wenn ich selbst mit diesen über Google suche, finde ich umgehend auch genau die Threads, die in diesem Zusammenhang eine Rolle spielen - solange ich das Modell und "die Software" suche (egal, ob die ausgeschriebene Form dazukommt oder nicht).

Sortiert man die Ergebnisse dann noch nach dem Datum absteigend (weil es logisch sein dürfte, daß ältere Erkenntnisse durch neuere ersetzt werden können), dann landet man direkt beim richtigen Thread - die Überschriften kann man nun mal auch nur für ein "Thema" vergeben und auch wenn sie das "Hauptthema" eines solchen Threads beschreiben, gibt es (wie in der Musik auch) eben Variationen dieses Themas und manchmal ist eben eine Erklärung oder Anleitung mit minimalsten Anpassungen auch für andere Zwecke zu verwenden.

Schon die Übersicht der Dateinamen in den Repositories (ja, dazu muß man sie irgendwie herunterladen oder einen anderen Weg finden, sie zu durchsuchen) sollte genug Hinweise liefern, wenn eine Datei am Ende "implant_siab.7412" heißt - die Suche mag mühsam sein, aber das erneute "Zusammenfassen" von Informationen ist/wäre es ebenso und dabei ist von mir eben wenig anderes zu erwarten, als etwas Ähnliches zu dem, was ich bisher geschrieben habe (wenn ich es anders machen wollte, hätte ich es - vermutlich - in den meisten Fällen schon im ersten Anlauf gemacht) und dazu kommt dann noch das Problem, daß man es unmöglich allen recht machen kann und selbst nach der nächsten "Anstrengung" garantiert wieder jemand käme, der das alles noch ganz anders haben will.

Es gibt von mir das, was es gibt ... es kostet nichts und außer Zeit und Geduld muß niemand etwas investieren, wenn er diese Software und die Erkenntnisse, die er aus irgendwelchen anderen meiner Beiträge ggf. ziehen kann, selbst nutzen will. Ich muß es leider immer wieder (auch in anderen Threads) betonen: Aus der Tatsache, daß man einmal etwas veröffentlicht, was andere bei Bedarf nachnutzen dürfen, ergibt sich nicht zwangsläufig die Verpflichtung, dieses auch noch so aufzubereiten, daß es tatsächlich für jeden "paßt" - ja, am Ende noch nicht einmal die Verpflichtung, das irgendwie aktuell zu halten. Manchmal wird das leider vergessen ... auch dann, wenn man sich tatsächlich bemüht, bei Problemen damit weiterhin hilfreich zur Seite zu stehen.

 

[rk97]

[...] wenn ich selbst mit diesen über Google suche

Aha?! Ich habe natürlich die Suchfunktion des Forums genommen, also rechts oben. Google würde ich nie zum Suchen verwenden.

Schon die Übersicht der Dateinamen in den Repositories [...]

Dazu muß man wissen, daß Du was auf Github veröffentlichst, siehe oben. Und ja, das finde ich sehr gut.

 

[stoney]

Google würde ich nie zum Suchen verwenden.

Googlesuche > site:ip-phone-forum.de Suchbegriff1+Suchbegriff2

 

[PeterPawn]

Und selbst wenn man Google nicht benutzen will ... irgendeine Suchmaschine muß man halt nehmen und auch DuckDuckGo findet die Threads im IPPF. Ein "ich finde nichts" erfordert eben immer auch die Angabe, wo und mit welchen Begriffen man eigentlich gesucht hat, wenn man die "tatsächliche Qualität" der vorausgegangenen Suche beurteilen will.

Wenn ich mit "7412 SIAB" die Boardsuche befrage, finde ich auch alles (auf der ersten Seite bereits), was ich in diesem Kontext im Gedächtnis habe - vielleicht stehe ich solchen "Ich habe doch gesucht."-Aussagen (auch nicht nur in diesem Thread, denn das kommt ja immer wieder vor) daher immer so skeptisch gegenüber.

Nun mag "SIAB" vielleicht nicht ins Auge springen als Stichwort, wenn man davon zuvor nie gehört hat (u.a. deshalb habe ich das ja noch in #12 "erwähnt"), aber auch mit "7412 shell" finde ich (sogar ohne Angabe eines Autoren, weil man den auch nicht vorher kennen muß) in den ersten Ergebnissen praktisch dieselben Threads und immer mindestens einen, von dem dann auf die richtigen Stellen (aus meinem Blickwinkel zumindest) verlinkt wird.

 

[rk97]

Erkenntnisse und Bestätigung zum NTP: FritzOS 6.83 auf einer 7412 benutzt selbst den externen NTP-Server, der unter Netzwerkeinstellungen eingetragen ist. "chrony_enabled = yes" bedeutet, daß die Fritzbox NTP-Server im lokalen Netz ist. Ein "no" hat keine Auswirkung auf die Zeit im FritzOS. Ist bei den DHCP-Einstellungen (IPv4) ein interner DNS-Server eingetragen, wird dieser für die Namensauflösung vom NTP-Server verwendet. Aber genau nur dafür. Die Namensauflösungen z.B. für die SIP-Server gehen am internen DNS-Server vorbei. Die Fritzbox lief jetzt jeweils am 1.1.1970 um 1:00Uhr los. Es braucht tatsächlich etwas Zeit, bis sich die richtige Zeit zu den einzelnen Prozessen "herumgesprochen" hat. Z.B. Energiemonitor/Statistik schreibt offensichtlich in einen 24h-Puffer aufgrund der gerade vorliegenden Zeit und rechnet nicht ab Systemstart. Dieser Prozeß braucht viele Minuten, bis der richtig skaliert.

Allerdings findet sich in der Export-Datei unter tr069cfg jetzt wieder ein LastSuccessfulContact mit dem vermuteten Zeitpunkt der ersten Zeitsynchronisation. Leider. D.h. über TR-069 läuft doch noch was. Mal schaun, ob sich was ändert, wenn ich meinen DNS-Server zusätzlich mit IPv6 betreibe (aktuell im Export: "dnsprefer = tr069dnsprefer_ipv6").

Googlesuche > site:ip-phone-forum.de Suchbegriff1+Suchbegriff2

Schon klar, trotzdem merkt sich Google etwas zuviel zu meiner Person. Startpage und DuckDuckGo sind die Wahl und funktionieren genauso.

Eigenschaft der Suche mit einer externen Suchmaschine ist, daß diese das ganze Forum scannt.

 

[PeterPawn]

Auch das Verhalten des NTP-Clients in der FRITZ!Box ist hier (mehrfach) irgendwo beschrieben ... da gibt es nämlich neben der Möglichkeit, daß ein Server in der "ar7.cfg" gesetzt ist, noch viele andere denkbare Kombinationen (Server gesetzt, aber nicht erreichbar, kein Server konfiguriert, DHCP für WAN-Konfiguration (oder auch LAN, wenn kein Router-Mode) und NTP-Server in der Antwort enthalten, usw.) ... am Ende gipfelt das sogar in der versuchten Abfrage eines Pools (also einer "Pool-Adresse", die im NTP-Client fest verdrahtet ist), wenn ansonsten nichts anderes konfiguriert ist.

Ja, der "voipd" des FRITZ!OS verwendet tatsächlich eigene DNS-Abfragen und ggf. auch direkt die Server (egal, was unter "DNS-Server" eingestellt ist im GUI), die vom Provider gemeldet werden.

Täte er das nicht, würde mit 99% Wahrscheinlichkeit (vermutlich inkl. einiger Kommastellen mit einer "9") beim Einsatz eines eigenen DNS-Servers der SIP-Client gar nicht mehr klarkommen bei den "üblichen Kunden" ... entweder weil der eingetragene DNS-Server die internen Adressen der Registrare des Providers gar nicht kennt (da gibt es genug Konfigurationen, wo diese keine öffentlich auflösbaren Namen und teilweise nicht mal "richtige" öffentliche Adressen haben) und der Benutzer da trotzdem irgendwelche anderen eingetragen hat oder auch, weil es gar nicht so einfach ist, die dynamisch vom Provider beim PPP übermittelten Server-Adressen auf einem eigenen Server als Forwarder zu konfigurieren (dazu muß man die ja erst mal aus der Box herauskriegen). Aber auch dieses Verhalten des "voipd" ist eigentlich bekannt und dokumentiert ...

Ansonsten muß man zwischen den eigenen DNS-Abfragen der Box und denen von Clients unterscheiden, wobei die Clients ggf. den zu verwendenden DNS-Server vom DHCP-Server der Box bekommen können ... seit einigen Versionen auch einen, der nicht der in der Box selbst vorhandene DNS-Forwarder samt -Cache ist.

Ich weiß nicht, welche Abfragen die Box ansonsten noch so machen sollte aus Deiner Sicht ... aber die "Sonderrolle" haben eigentlich nur DNS-Namen in Verbindung mit dem "voipd" und alles andere - auch die Auflösung für Update-Suche, um mal ein Beispiel zu nennen oder die Auflösung eines SMTP-Servernamens für die Push-Mails - sollte über den im FRITZ!OS hinterlegten Server gehen.

Wobei man auch hier eben zwischen "Internet / Zugangsdaten / DNS-Server" (da steht der DNS-Server, den das FRITZ!OS verwendet, mit Ausnahme des "voipd") und dem unter "IPv4-Adressen" eingestellten (das ist der, der an die DHCP-Clients gesendet wird) unterscheiden muß - die können identisch sein, das ist aber kein "muß".

Bei korrekter Konfiguration des Providers ("anderer Anbieter") sollte gar kein TR-069 verwendet werden (ebenfalls ad nauseam durchgekaut in diversen Threads) ... solange da auf der WAN-Seite nicht tatsächlich DHCP verwendet wird und Option 43 einen ACS festlegt (und deren Verwendung "erlaubt" ist), was bei PPP-Kapselung m.W. auch nicht funktioniert, weil IPCP (darüber wird beim PPP L3 konfiguriert) eben kein DHCP ist.

Warum geht dann TR-069 eigentlich nicht? Weil bei TR-069 die initiale Kommunikation immer vom CPE ausgeht und solange dieses gar nicht weiß, wohin es "sich unterhalten" soll, kann da auch nichts funktionieren. Daher wird ja bei den ganzen providerspezifischen Konfigurationen (ob nun über die "providers-049.tar" in der Firmware und die Auswahl im GUI vorgegeben oder über eine "provider additive configuration" im TFFS-Node 29) auch in allererster Linie ein passender ACS gesetzt, damit sich die Box auch mit "Standardangaben" erst einmal mit dem ACS überhaupt verbinden kann. Ohne diese URL, steht sie nur still da und harrt der Dinge, die da kommen.

Aber wie gesagt ... auch alles (gefühlt) hunderte Male ausdiskutiert. Wer im GUI irgendeinen der vorbereiteten Provider auswählt, der konfiguriert eben die Box auch mit den Parametern, die AVM für diesen Provider in der Firmware hinterlegt hat.

Diese "Konfigurationsdatei" ist nun wirklich kein Geheimnis und jeder, der die Firmware in ihre Bestandteile zerlegt (auch das ist hier mehr als einmal beschrieben, wie das geht), kann direkt dort nachsehen, was für "seinen" Provider denn nun konfiguriert wird. Bei "Anderer Anbieter" steht da eben nichts drin ... und genau das wird dann auch konfiguriert, wenn man mit einer "frischen" Konfiguration (also "Werkseinstellungen") aufläuft.

EDIT: Inwieweit das FRITZ!OS jetzt bei einem NXDOMAIN (also "unbekannter Name") als Ergebnis einer Abfrage des unter "DNS-Server" eingetragenen Servers zusätzlich noch den bei den IPv4-Einstellungen konfigurierten befragt (wenn die sich unterscheiden), weiß ich aber gerade nicht bzw. das könnte sich auch - in Abhängigkeit von der LAN- und WAN-Konfiguration - von Fall zu Fall unterscheiden.

 

[stoney]

DuckDuckGo kann ebenso mit dieser Syntax etwas anfangen

https://duckduckgo.com/?q=site:ip-phone-forum.de+7412+shell&t=h_&ia=web

Aber nun gut. BackToTopic