[Info] FRITZ!Box 7590 / FRITZ!OS 8.25

fritzbox_reconnect.sh basiert wie viele anderen Funktionen auf UPnP und funktioniert nur noch von lokalen IPs aus mit aktivierter Option "Selbstständige Portfreigaben und das Trennen und Wiederherstellen der Internetverbindung für dieses Gerät erlauben".
Dass man die nützliche Funktion "reconnect" mit dem risikoreichen "Selbstständige Portfreigaben ... erlauben" kombiniert, erzeugt bei mir einen leichten Brechreiz.
 
  • Like
Reaktionen: NanoBot
Eben ging es bei dir noch so "fritzbox_reconnect.sh geht nicht mehr". Was jetzt?
Bei mir geht bei einer 7690 (8.24-130896 BETA) kein reconnect mehr per VPN und bei einer 5590 (8.24-131081 Inhaus) ging es erst nach der Aktivierung der von mir oben genannten NEUEN Option.
 
okay, danke. ich meinte ging früher auch so.
Habe das script ändern müssen und jetzt geht's auch wieder
 
Leider hat die Fritzbox mit der aktuellen Firmware, so wie auch in früheren Versionen von FritzOS, weiterhin ein Problem mit DoT bei Quad9. Im Gegensatz zu anderen Resolvern wie Cloudflare oder Google schaukeln sich die Antwortzeiten im Laufe der Zeit hoch und vermitteln dann beim betroffenen Endgerät den Eindruck, als ob die DNS-Verbindung zu Quad9 performancetechnisch beeinträchtigt oder sogar ausgefallen ist.

Hier gibt es eventuell ein Timingproblem, weil Quad9 die Keepalive-Timer grosszügiger als andere Anbieter setzt.

Zudem wäre bei aktivem DoT eine kleine Statistik bzgl. der Verteilung auf die hinterlegten Resolver nützlich (letzter Tag/letzte Woche/letzter Monat) - bei zwei EInträgen dann 'z.B. 35% Resolver A, 65% Resolver B).
 
  • Sad
Reaktionen: Deleted member 479035
Schon mal vorab: Ich nutze auf der Fritzbox den normalen Telekom DNS. Mit der 8.20 und 8.21 und auch späteren Labors hatte ich unglaublich oft Hänger beim Öffnen oder Reload von Webseiten. Oft musste man auf dem Ipad den entsprechenden Browertab sogar komplett abschießen. Manche Webseiten gingen gar nur über LTE, nicht über Festnetz (VDSL 175 mit Vectoring über Draytek Modem davor). Seit 8.25 ist dieses nervige Verhalten weg. Auch sind die immer wieder auftretenden grottigen Streams mit Hängern passé.
 
Zuletzt bearbeitet:
Manche Webseiten gingen gar nur über LTE, nicht über Festnetz [... ] Seit 8.25 ist dieses nervige Verhalten weg.
So hat es sich mir auch dargestellt, wobei ich einen Telekom-Glasfaseranschluß nutze und unterschiedliche DNS-Server verwendet habe.
 
[…] Kabel-Kunden kennen diese Menükonstellation.
Nicht nur Kabelkunden kennen das, es gibt auch andere nonCable Netzbetreiber, die bei ihren Boxen (mit Provider-Additive) die Updatefunktion ausblenden (bspw. MNet). Aber die DG gehört meiner Erfahrung eben nicht zu diesen, zumindest nicht seit ich die ersten DG Kunden kenne. Mag vielleicht sein, dass die DG in der Anfangszeit bei ihren eigenen Boxen das tatsächlich mal gemacht hatte, aber in den letzten Jahren (also bei den Boxen von der DG) ist das meiner Erfahrung nach nicht mehr der Fall.

Und ganz bestimmt ist (und war) das nicht der Fall, wenn man eine eigene Retail-Box verwendet.

Die nun Kundeneigene Nachfolgebox hat DG auch wieder kastriert…
Da vermute ich als Ursache eher ein anderes Problem und nicht die DG, vielleicht wurde beim Wechsel der Boxen mal die Konfiguration der vorherigen Box auf die neue importiert. Dabei werden dann eben auch Einstellungen bzgl. der Sichtbarkeit der Updatefunktion mit übernommen (s.h. entspr. Parameter in Beitrag #32). Das Problem ist dann also nicht die Provisionierung seitens der DG. Denn spätestens mit einer eigenen (Retail)-Box darf das nicht passieren (zumindest wenn man nicht die Konfiguration einer DG-Box importiert sondern diese selbst einrichtet).

Keine Ahnung, wie DG dein Netzsegment verwaltet. In dem, mit dem ich es zu tun habe, hat DG es offenbar so gelöst.
Man kann davon ausgehen (bzw. ich gehe nach wie vor davon aus), dass die DG in keinem Netzsegment kundeneigene Router verwaltet. Bzw. wenn sie das tut, dann ist das (siehe oben) vermutlich gar nicht das Verschulden der DG…
 
Laut Aussage von Quad9 werden sie in den kommenden Tagen den IdleTimeout für TCP-basierte Protokolle von 30s auf 180s erhöhen - eventuell hilft dies ja bei den ‚Eigenheiten’ der Fritzbox bzgl. einer DoT-Verbindung zu Quad9.
 
Laut Aussage von Quad9
Mit quad9 hat es in den letzten Tagen reichlich Probleme gegeben mit verschiedenen Routerherstellern. Nutzt man aber die DNS Server vom Provider, dann sind die Probleme plötzlich nicht mehr da. Die Ursache dafür "Quad9 Enables DNS Over HTTP/3 and DNS Over QUIC. Quad9 has enabled DNS over HTTP/3 (DoH3) and DNS over QUIC (DoQ) across its global resolver network. DNS transport protocols have continued to evolve since Quad9 first launched and following that evolution is part of how Quad9 serves users who care about the privacy and security of their queries."
 
Der Quad9-Support ist sich zumindest der Allgegenwärtigkeit der Fritzbox bewusst
Warum hat man dann von dort aus nicht voher die Anpassungen kommuniziert? Hinterher dem Ganzen nur einen Blogbeitrag zu widmen ist ziemlich wohlfeil. Jetzt sollen offenbar die Routerhersteller dafür auch noch Firmwareanpassungen liefern, weil quad9 etwas "verbessert" hat. Besser einfach andere DNS Server nutzen.
 
Der Quad9-Support hat nun gemeldet, dass der IdleTimeout für TCP-basierte Protokolle auf 180s erhöht wurde - hat aber bei mir bzgl. DoT auf der Fritzbox zu Quad9 keine Behebung des Problems gebracht. Eine Gegenprüfung mit unverschlüsseltem DNS auf der Fritzbox zu Quad9 hat dies nochmal bestätigt... hier gibt es keine Probleme, DNS Roundtrip-Zeit 10-28ms.
 
Ich hatte bisher keinerlei Probleme mit Quad9.
Ich nutze Quad9 schon seit Jahren und aktuell mit Telekom GF.
 
Zuletzt bearbeitet von einem Moderator:
@Farelo
Ja, jedoch habe ich den Fallback auf die Provider DNS Server aktiviert, da ich keine Ausfälle haben möchte.
Bisher habe ich aber noch keinen Ausfall von Quad9 mitbekommen und bisher immer verschlüsselte IPs von Quad9 bekommen.
Zudem habe ich keine speziellen IPs eingetragen, wie es hier viele machen, sondern im Eingabefeld in der Fritzbox nur die DNS Domain von Quad9 eingetragen.
 
Betreff: FRITZ!OS 8.25 mit Vigor 167 (oder ähnlich) – läuft's jetzt?

Hallo Leute,

gibt es bei der Version 8.25 immer noch Probleme mit externen Modems wie Vigor 167? Ich bin im Moment noch auf 8.03, weil 8.20 damit absolut nicht läuft – keine Internetverbindung mehr über WAN, trotz korrekter Config. Habe damals mit Recovery zurückgerollt.

Hat jemand Erfahrungen mit 8.25 + Vigor (z. B. 167) getestet? Läuft Ausfallschutz/WAN stabil, oder wieder Drama?

Danke für Feedback!
Chris
 
Läuft wieder perfekt am Telekom Anschluss mit vordefiniertem "Telekom" Profil und Vigor 165. Also vermutlich auch mit dem Vigor 167. Das PPPoE kommt dann Vlan 7 getaggt aus dem WAN Port raus, also auf dem Vigor dann bitte abermaliges Taggen deaktivieren. Das Vigor arbeitet dann als purer Medienwandler Ehernet auf (Super)Vectoring. Den Ausfallschutz via zusätzlichem Mobilfunk kann ich nicht beurteilen, da ich ihn nicht nutze,
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Deleted member 479035
Ok ich habe das update gerade gemacht,
Ich habe im Zuge dessen auch die Repeater 2400er auf 8.20 gebracht ich hoffe das war kein Fehler.

Oder ist es besser dort die neueste Laborversion -131247 drauf zu bügeln?
 
Zuletzt bearbeitet von einem Moderator:
Kostenlos!

Statistik des Forums

Themen
248,871
Beiträge
2,303,449
Mitglieder
378,532
Neuestes Mitglied
Nik320