Sammelthema für FB 7590 mit Firmware "Intern"/"Inhaus" bis 07.22

Moin

Vielleicht, vielleicht auch nicht.
Ich mach TR-069 als "Ersteinrichtungshilfe" und deaktiviere es anschliessend.
Vielleicht bist du ja schlauer als ich und kannst mit den Daten, die die LUA Konsole ausspukt was anfangen ?
Code:
koy_ctl = function(mod)
return io.write(
"<!DOCTYPE html>",
"<html>",
"<head><title></title></head>",
"<body>",
"<h3>ctlmgr_ctl "..mod.."</h3>",
"<pre>",
-- Null ( 0 ) bedeutet: Hat geklappt
os.execute("ctlmgr_ctl "..mod),
"</pre>",
"</body>",
"</html>"
)
end

koy_ctl('u tr069')
In die LUA Konsole einfügen und ausführen ( Nur Lesend )
 
Zuletzt bearbeitet:
Das ist nicht lustig.
Defrag war mein Lieblingsspiel unter MS-DOS.
:rolleyes: ( aka Speeddisk )
 
Zuletzt bearbeitet:
Der Zahlendreher war einfach zu verlockend - ab in die Spaßecke damit.
 
  • Like
Reaktionen: Meeeenzer
hmmm eventuell kam der Zeitserver auch nicht per TR069 sondern mit dem Update? War bei mir auf jedenfall auch aktiv!
 
Meinst du nicht, dass Telekom Kunden einen ziemlich dicken Hals bekämen, wenn auf einmal 1und1 Zeugs in ihrer Kiste auftauchen würde ?
...womöglich mit so einer gravierenden Zeitverschiebung wie es mir passiert ist.
 
Hallo zusammen,

ich habe zwar die letzte Labor und nicht die Inhouse auf meinen FritzBoxen installiert, aber auch da hat sich bei meinem Telekom VDSL-Anschluss ein zusätzlicher NTP (ntp1.t-online.de) eingeschmuggelt. Ich würde daher auch eher auf eine Ergänzung mit dem letzten Update tippen, weil ich meine Boxen immer manuell mit Zugangsdaten und nicht per TR069 einrichte.

VG
Mopedmeister
 
AVM hat in den letzten Versionen (seit Mitte April) (EDIT: die Zeitangabe ist falsch, ich habe die Änderungen auch in deutlich älteren Versionen gefunden, allerdings sind wohl die (NTP-)Änderungen bei 1&1 erst irgendwann zwischen Weihnachten 2017 und Februar 2018 in die Labor-Reihe eingebaut worden) die "providers-049.tar" überarbeitet und setzt jetzt bei vielen der vorbelegten Provider auch den NTP-Server (und daß diese Datei nicht nur bei der Erstkonfiguration zurate gezogen wird, ist schon länger bekannt - dann muß man eben "anderer Anbieter" nehmen):
Code:
vidar:/tmp/providers # grep -rn -A 3 ntpclient
kielnet_gf/ar7.cfg:25:ntpclient {
kielnet_gf/ar7.cfg-26-        server_list = "ntp1.versatel.de", "ntp2.versatel.de", "2.europe.pool.ntp.org";
kielnet_gf/ar7.cfg-27-}
kielnet_gf/ar7.cfg-28-
--
htpngn_vdsl/ar7.cfg:65:ntpclient {
htpngn_vdsl/ar7.cfg-66-        server_list = "2.europe.pool.ntp.org", "ntp.htp-apv.de";
htpngn_vdsl/ar7.cfg-67-}
--
otwored/ar7.cfg:34:ntpclient {
otwored/ar7.cfg-35-        server_list = "ntp0.voip.telefonica.de", "ntp1.voip.telefonica.de";
otwored/ar7.cfg-36-        chrony_enabled = yes;
otwored/ar7.cfg-37-}
--
o2_lte/ar7.cfg:9:ntpclient {
o2_lte/ar7.cfg-10-    server_list = "ntp0.voip.telefonica.de", "ntp1.voip.telefonica.de";
o2_lte/ar7.cfg-11-}
o2_lte/ar7.cfg-12-// EOF
--
htpngn_fiber/ar7.cfg:114:ntpclient {
htpngn_fiber/ar7.cfg-115-        server_list = "2.europe.pool.ntp.org", "ntp.htp-apv.de";
htpngn_fiber/ar7.cfg-116-        chrony_enabled = yes;
htpngn_fiber/ar7.cfg-117-}
--
htpdsl_vdsl/ar7.cfg:63:ntpclient {
htpdsl_vdsl/ar7.cfg-64-        server_list = "2.europe.pool.ntp.org", "ntp.htp-apv.de";
htpdsl_vdsl/ar7.cfg-65-}
htpdsl_vdsl/ar7.cfg-66-
--
kielnet/ar7.cfg:18:ntpclient {
kielnet/ar7.cfg-19-        server_list = "ntp1.versatel.de", "ntp2.versatel.de", "2.europe.pool.ntp.org";
kielnet/ar7.cfg-20-}
kielnet/ar7.cfg-21-
--
o2_lte2/ar7.cfg:9:ntpclient {
o2_lte2/ar7.cfg-10-    server_list = "ntp0.voip.telefonica.de", "ntp1.voip.telefonica.de";
o2_lte2/ar7.cfg-11-}
o2_lte2/ar7.cfg-12-// EOF
--
kielnet_vdsl/ar7.cfg:28:ntpclient {
kielnet_vdsl/ar7.cfg-29-        server_list = "ntp1.versatel.de", "ntp2.versatel.de", "2.europe.pool.ntp.org";
kielnet_vdsl/ar7.cfg-30-}
kielnet_vdsl/ar7.cfg-31-
--
ewetel_allip2/ar7.cfg:49:ntpclient {
ewetel_allip2/ar7.cfg-50-        server_list = "ntp.ewetel.de", "2.europe.pool.ntp.org";
ewetel_allip2/ar7.cfg-51-        chrony_enabled = yes;
ewetel_allip2/ar7.cfg-52-}
--
htpngn_adsl/ar7.cfg:79:ntpclient {
htpngn_adsl/ar7.cfg-80-        server_list = "2.europe.pool.ntp.org", "ntp.htp-apv.de";
htpngn_adsl/ar7.cfg-81-}
--
1und1_elte/ar7.cfg:4:ntpclient {
1und1_elte/ar7.cfg-5-   server_list = "ntp.1und1.de";
1und1_elte/ar7.cfg-6-   fallback_server = "2.europe.pool.ntp.org";
1und1_elte/ar7.cfg-7-}
--
1und1/ar7.cfg:6:ntpclient {
1und1/ar7.cfg-7-   server_list = "ntp.1und1.de";
1und1/ar7.cfg-8-   fallback_server = "2.europe.pool.ntp.org";
1und1/ar7.cfg-9-}
--
telekom_tr069/ar7.cfg:124:ntpclient {
telekom_tr069/ar7.cfg-125-    server_list = "ntp1.t-online.de", "ptbtime1.ptb.de", "ntp1.iptv.t-online.de";
telekom_tr069/ar7.cfg-126-    chrony_enabled = yes;
telekom_tr069/ar7.cfg-127-}
--
1und1_lte/ar7.cfg:4:ntpclient {
1und1_lte/ar7.cfg-5-   server_list = "ntp.1und1.de";
1und1_lte/ar7.cfg-6-   fallback_server = "2.europe.pool.ntp.org";
1und1_lte/ar7.cfg-7-}
--
otwored_ftth/ar7.cfg:42:ntpclient {
otwored_ftth/ar7.cfg-43-        server_list = "ntp0.voip.telefonica.de", "ntp1.voip.telefonica.de";
otwored_ftth/ar7.cfg-44-        chrony_enabled = yes;
otwored_ftth/ar7.cfg-45-}
--
ewetel_allip/ar7.cfg:49:ntpclient {
ewetel_allip/ar7.cfg-50-        server_list = "ntp.ewetel.de", "2.europe.pool.ntp.org";
ewetel_allip/ar7.cfg-51-        chrony_enabled = yes;
ewetel_allip/ar7.cfg-52-}
--
htpdsl_adsl/ar7.cfg:61:ntpclient {
htpdsl_adsl/ar7.cfg-62-        server_list = "2.europe.pool.ntp.org", "ntp.htp-apv.de";
htpdsl_adsl/ar7.cfg-63-}
htpdsl_adsl/ar7.cfg-64-
--
1und1_dlte/ar7.cfg:4:ntpclient {
1und1_dlte/ar7.cfg-5-   server_list = "ntp.1und1.de";
1und1_dlte/ar7.cfg-6-   fallback_server = "2.europe.pool.ntp.org";
1und1_dlte/ar7.cfg-7-}
--
tonline/ar7.cfg:6:ntpclient {
tonline/ar7.cfg-7-    server_list = "ntp1.t-online.de", "2.europe.pool.ntp.org";
tonline/ar7.cfg-8-}
tonline/ar7.cfg-9-
vidar:/tmp/providers #
Das ist also keine über TR-069 gesetzte Einstellung - was AVM hier dazu verleitet hat und vor allem, wie sich das mit einem vom Besitzer bereits festgelegten (privaten) NTP-Server verträgt, muß man wohl abwarten ... hoffentlich ist das für AVM nicht der Startschuß zur Abschaffung oder zum "Verstecken" (oder Deaktivieren) der Einstellung im GUI EDIT: ... eher nicht, die Änderung betraf wohl doch nur die 1&1-Einstellungen in der "providers-049.tar" (Korrektur s.o.).

Blöd an so einem NTP-Server beim Provider ist es halt, daß man darüber den Client (und wenn der ein Router ist und für sein LAN auch die Time-Source, auch noch nachfolgende Geräte) austricksen kann, sofern man nicht spezielle Abwehrmöglichkeiten dagegen vorgesehen hat (z.B. den größten, jemals "valide" bekanntgemachten Wert gesondert speichern und ein Zurückfallen hinter diesen Wert dann nicht mehr zulassen, weil die (reale) Zeit wohl nur monoton steigende Werte aufweist) ... wie man an der Box von @koyaanisqatsi wohl sehen kann/konnte.

Das würde z.B. beim Validieren von Zertifikaten mit Ablaufdatum einen denkbaren Angriffsvektor bilden ... wobei man mit so richtig fetten Manipulationen auch jede Menge anderen Unsinn anstellen kann, weil z.B. auch Update-Abfragen oder Abonnements (z.B. von Schlangenöl-Subscriptions) da gerne mal durcheinander geraten. Insofern wäre eine etwas genauere Prüfung über mehrere Server (das NTP-Protokoll sieht das ausdrücklich vor) wohl deutlich besser und sicherer, als die Festlegung auf irgendeinen (einzelnen) NTP-Server bei einem Provider, der eben durchaus falsche Werte übermitteln kann bzw. von jemandem manipuliert sein könnte. Ob die Angabe mehrerer Server (wie z.B. beim "telekom-tr069"-Eintrag oben) auch zur Abfrage aller dieser Server führt (bzw. zu irgendeinem aus dem Pool, wenn es eine Pool-Adresse ist) und dann tatsächlich abgewogen wird, muß man mal nachsehen ... in der Support-Datei sollte auch das "chrony"-Log zu finden sein.

Ein absichtliches Einstellen der falschen Uhrzeit ist bei mehr als einem (unabhängigen) Server dann deutlich schwerer und auch wenn die korrekte Uhrzeit für eine FRITZ!Box immer wichtiger wird (jetzt rächt es sich, daß die keine eigene RTC haben) und nicht jede Box sofort vom Provider auch "ins Internet" durchgelassen wird (viele Provider haben inzwischen interne Aktivierungsportale - u.a. auch die Swisscom, wie ich gestern erst wieder feststellen konnte -, bei denen dann zwar schon eine "Internet-Verbindung" besteht, die aber auf das lokale Netz des Providers beschränkt ist, bis sich der Benutzer irgendwie authentifiziert ... ähnlich wie in irgendwelchen "captive portals" bei WLAN-APs), ist das wieder eine neue Möglichkeit der Manipulation, die man durch den Vergleich mehrerer Angaben problemlos (zumindest etwas) entschärfen könnte. Keine Ahnung, ob eine LTE-Box z.B. Zugriff auf die Zeit aus dem Mobilfunk hätte ... das wäre eine weitere, unabhängige Quelle.

So ein "Unfall" wie bei @koyaanisqatsi wäre eben auch dadurch vermeidbar, daß die FRITZ!Box ab und an mal (bei wichtigen Ereignissen, spätestens beim Datumswechsel und beim täglichen Mailversand) einen Zeitstempel speichert (der muß nicht mal exportiert werden) und dann irgendwelche Werte, die sie von einem NTP-Server erhält, auf eine maximal mögliche und plausible Differenz zum letzten bekannten Wert testet, bevor diese als aktuelle Zeit akzeptiert werden. Unplausible Werte erfordern dann eben die Reaktion des Besitzers oder den Vergleich mit weiteren Quellen ... eine "Zwangssynchronisation" mit einem Server auf Knopfdruck (im GUI) wäre dann eine Lösung, bei der auch ein "normaler Benutzer" eher nicht überfordert wird und mit der man solche Widersprüche beseitigen könnte.

Es kommt halt darauf an, für wie wichtig man die genaue und korrekte Zeitangabe hält ... schon für den Vergleich von Anruflisten (bei Fraud-Verdacht) beim Provider und in der Box ist es eben essentiell, daß die Zeitdifferenz unterhalb einer max. akzeptablen Abweichung (das dürften nur ganz wenige Sekunden als Maximum sein, besser sogar < 1 Sek.) bleibt.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: NDiIPP
Moins

Aha, Defaulteinstellungen ( Werkseinstellungen laden ) tragen den also ein.
...danke für die Detektivarbeit ;)

Ich hatte noch keinen Neustart, also auch keine "Neuzeit" von dem inzwischen auf...
times.tubit.tu-berlin.de
...geänderten Zeitserver bekommen.

Dabei fielen mir 3 verschiedene Datum/Zeiten auf...
1. DSL Verbindungsdauer
2. Anrufslistenzeit
3. Ereignislogzeiten

Das sieht dann ( nach der Zwangstrennung ) so aus...
1. Zwischenablage01.png <--<< inkorrekt aber von 13. auf 14. gesprungen ( durch ZT* )

2. Zwischenablage01.png <--<< inkorrekt ( Datum korrekt, aber Zeit voll daneben :D )

3. Zwischenablage01.png <--<< inkorrekt ( Verstehe wer will )

Eigentlich dachte ich auch, die Uhrzeit synchronisiert sich, zumindest für Anrufsliste/Ereignsislog, irgendwann automatisch mit den neuen Zeitserver.
...auch ohne einen Neustart der Box.


* Zwangstrennung
 
Zuletzt bearbeitet:
Ich habe nachts die WLAN-Zeitschaltung aktiviert und dank Mesh-Telefonie leuchtet beim Mesh-Repeater jetzt jeden Morgen die Info-LED rot; bei Ereignissen steht dann sinngemäss, das eine Internetrufnummer XYZ123456789abc@net nicht erreichbar gewesen sei.
 
Wenn dein Mesh-Repeater über WLAN mit dem Mesh-Master verbunden ist, dann ist das logisch.
 
@alexandi Kannst Du die "Logik" erläutern? Hier arbeitet eine 7490 ausschliesslich als Repeater via WLAN mit eigenen SIP-Accounts. Würde ich die SIP-Accounts "meshen" (wohl die Telefonie?) verspreche ich mir davon herzlich wenig, da das DECT-Signal eben mangels Repeaterfähigkeit nicht gemesht wird. Sämtliche SmartHome-Gerätschaft basiert gleichfalls auf DECT, wo seit geraumer Zeit die Schaltmöglichkeit auf die DECT-Masterbox beschränkt ist, selbst wenn sie nur IP-Client ist (gemesht oder auch nicht)
LG
 
OK ich werf meine "Logik" in den Mülleimer.
Muß ja ein eigenen SIP-Account haben. Telefonie meshen geht ja nur bei IP-Clients

wo seit geraumer Zeit die Schaltmöglichkeit auf die DECT-Masterbox beschränkt ist
Das wiederum stimmt nicht. Meine DECT's kann ich von jedem IP-Client schalten der eingemesht wurde
 
Bei mir macht das Sinn, mein DSL Anschluss ist im Erdgeschoss unter der Treppe und mein Büro mit Fax ist im 2. OG und mit der Mesh funktioniert mein Fax wieder, weil eine 2. Box oben neben dem Fax steht und mit Kabel an der der gemeshten Box angeschlossen ist.
 
Danke @alexandi für #935. Ein möglicher Vorteil, der mir durch "gespiegelte SIP-Accounts" einfiele, wären Telefonie-Apps im WLAN, falls zwei Fritz!Boxen weit auseinander betrieben werden und per LAN-Kabel verbunden sind. Die Voice-Pakete müssen imho ja priorisiert werden, was sich durch gespiegelte SIP-Accounts u.U. intern besser regeln lässt.

LG and my2cent
@Komet-0818
Dein FAX-Gerät wird wohl eher nicht per DECT verbunden sein und während des FAXens in den Keller bewegt?
 
Zuletzt bearbeitet:
Hi,
Update verlief Ohne Probleme

VDSL-Version: 1.180.129.30
DECT-Version: 5.53

Gruß
Basti

Zusätzlich wird ein Update für meinen 450E angezeigt (Nur in der Fritzbox, nicht direkt im Repeater unter Update), dieses habe ich schon mehrmals angestoßen aber wird nicht Installiert. Es bleibt bei der 06.92 und es erscheint immer wieder Update ausführen in der FritzBox.
Auch nach mehreren Neustarts und einem POR der Fritzbox und des Repeaters ist nichts zu machen, das Update will nicht o_O;)
 
Zuletzt bearbeitet:
Traurig aber wahr: Namen im IP-Client immer noch Fehlanzeige
 
1750 WLAN Repeater erhält automatisches Update auf 06.98-55604 Inhaus
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,361
Beiträge
2,250,846
Mitglieder
374,014
Neuestes Mitglied
flindiesel
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.