[Info] FRITZ!Box 7590 Fritz!OS 154.07.00 Release vom 24.07.2018

Die per RA bekanntgegebenen DNS-Server auf der WAN-Seite zu ignorieren, hat auch FRITZ!OS 7 noch nicht gelernt ... es gibt m.W. auch keine Einstellung (vielleicht noch direkt in der "ar7.cfg" bei den IPv6-Optionen, habe ich noch nicht probiert).

Du solltest an der 7490 die Bekanntgabe des DNS-Servers per DHCPv6 aktivieren (irgendwo bei den IPv6-Netzwerkeinstellungen) und die Router-Advertisements (für spätere Leser: das sind diese "RA", die ich oben angesprochen habe) für den DNS-Server abstellen (an derselben Stelle).

Dann sollte in der 7590 auch das Übersteuern der DNS-Server unter "Zugangsdaten" funktionieren ... solange da RAs kommen, überstimmen diese auch die GUI-Einstellungen (jedenfalls nach dem, was ich bei Tests festgestellt habe).

PS: Bevor es wieder in Vergessenheit gerät: Der "voipd" der FRITZ!Box verwendet in jedem Falle die DNS-Server "vom Provider" ... hier also auch den, den die kaskadierte Box auf der WAN-Seite von der 7490 erhält.

Wie das im Einzelnen aussieht, kann man sich in der Support-Datei bei den Interfaces des "voipd" ansehen und auch beim "DSL-Status" (der eigentlich "WAN-Status" heißen müßte). Die Inhalte der "/etc/resolv.conf" (das ist der DNS-Server, der von der Box selbst verwendet wird - praktisch von allem, was über die C-Library arbeitet) und der "avm-resolv.conf" (hier steht "der originale DNS-Server" vom Provider) sollten sich da auch irgendwo finden lassen. Notfalls muß man mit einer Shell etwas nachhelfen - wobei die Auflösung für die "nachgelagerten Clients" (die ja die kaskadierte Box und deren DNS-Resolver benutzen, der wiederum bei Auflösungen auch dann auf die "überschriebenen" DNS-Server zurückgreift, wenn er per DNS oder RA anderes gelernt hat) eigentlich immer funktionieren sollte.

Wo man auch noch aufpassen muß ... der DNS-Server auf der WAN-Seite darf keine "normale" ULA-Adresse verwenden (aus "fd00::/8"), weil die FRITZ!Box (auch mit FRITZ!OS 7) keine Route dorthin einrichtet bzw. (zumindest bei mir, als ich es von Hand gemacht hatte) das Routing an eine konkrete IPv6-Adresse mit /128-Maske über "dev dsl" auch nicht funktioniert (allerdings hatte ich mit 153.07.00 getestet).

Will man tatsächlich die per RA vom Edge-Router übermittelte DNS-Adresse benutzen, sollte man dafür sorgen, daß es die "link local"-Adresse des Edge-Routers (also die aus "fe80::/10") ist, denn für solche Adressen macht auch AVM offensichtlich die passende Auflösung per "Neighborhood Solicitation" und sucht auch hinter "dev dsl" nach der passenden Antwort.
 
Zuletzt bearbeitet:
Die Clients hinter der kaskadierten Box (7590) benutzen ein Pihole, dessen IPv4- und ULA sie vom DHCP der Box erhalten. Das funktioniert auch hervorragend, da die DNS-Requests des Pihole ja lediglich ein Gate brauchen. Die Idee war, Anfragen der Box selbst auch über den Pi laufen zu lassen, aber wie gesagt: Ich darf das so angeben, die Übernahme wird auch ausführlich im Log beschrieben, aber weiter die vorgelagerte 7490 benutzt, wie es aussieht auch eben nur via IPv4 (wegen ULA).
Der nächste Versuch bestand darin, statische Adressen an der WAN-Schnittstelle zu benutzen, statt DHCP. Das führte immerhin zu der Erkenntnis, dass für die 7590 der DNS-Server immer im WAN liegen muss. Der Versuch, die Adressen des Providers zu benutzen, führte wiederum zur vorher schon gewonnen Erkenntnis: Es ist der 7590 egal, was man da einträgt, sie benutzt sie einfach nicht.

Interessant finde ich deine Aussage zur Verwendung der LinkLocal der vorgelagerten 7490 in deren RA. Damit hatte ich auch schon einmal experimentiert, bin da aber auch nicht weiter gekommen, was ein weiteres Argument zum Einsatz des Pihole war. Aber probieren kann ich das ja nochmal, vlt, ist mir da auch ein Fehler unterlaufen.
Nachtrag: Ich hatte bei dem Versuch die LinkLocal der vorgelagerten Box an die Clienten weitergegeben. Das funktioniert natürlich nicht, weil weder LinkLocals noch ULAs geroutet werden. Ob die Box als WAN-Client damit etwas anfangen kann, hatte ich nicht untersucht.
 
Zuletzt bearbeitet:
Die Verwendung des PiHole als Filter spricht ja nicht automatisch dagegen, die FRITZ!Box als Forwarder zu nutzen ... wobei ich nicht so richtig verstehe, warum die FRITZ!Box selbst auch über das PiHole gehen soll. Die macht ja eher keine unerwarteten DNS-Abfragen wg. irgendwelcher eingebetteten Werbung in HTML-Seiten oder ähnliches ... die "Ziele" ihrer selbstinitiierten Kommunikation im Internet sind einigermaßen vorbestimmt und da greift man entweder ein, indem man die abfragenden Dienste stilllegt oder man läßt es gänzlich sein - hier mit DNS-Spoofing zu arbeiten (auch ein "NXDOMAIN" ist ein solches Spoofing, wenn es aus dem Unterdrücken einer Anfrage stammt), ist eher gefährlich und (m.E. jedenfalls) unnütz. Da ist dann das Umbiegen des AVM-Netzes (212.42.244.0/24) über "dev lan" auch wieder erfolgversprechender als Blockade jedes Kontakts mit AVM bzw. zum Einschleusen eines Anderen als MITM-Proxy.

Das führte immerhin zu der Erkenntnis, dass für die 7590 der DNS-Server immer im WAN liegen muss.
Das finde ich nun wieder interessant ... wie kommst Du darauf? Wobei die Frage halt auch wäre, was hier die "statische Konfiguration" von Adressen ist, die Du meinst ... für die gesamten IPv6-Einstellungen oder nur für die DNS-Server? Das eine wäre bei "IPv6 -> Statische Einstellungen nutzen" und das andere unter "DNS-Server -> DNSv6-Server" - beides unterhalb von "Internet -> Zugangsdaten" (falls spätere Leser suchen sollten). Gab es bei Dir tatsächlich eine entsprechende Route zum DNS in der FRITZ!Box?

Vielleicht hatte ich auch nur das Glück, daß ich keine IPv4-Konfiguration für die kaskadierte Box hatte (die somit auch keine DNS-Abfragen über IPv4 machte) ... iirc steht z.B. in der "/etc/resolv.conf" bei AVM immer die "127.0.0.1" und nicht die "::1" als NS-Adresse.

Ich stand vor einer guten Woche vor der Aufgabenstellung, an einem M-net-Anschluß hinter einer 7430 vom Provider, die ihre Konfiguration per TR-069 auch von dort bezieht und nicht entfernt/zu sehr modifziert werden soll, damit der Provider im Support-Fall nicht einfach die Hände heben und sich für "nicht zuständig" erklären kann, eine Möglichkeit der Verbindung zu einem eigenen SIP-Server zu schaffen ... M-net läßt die Kunden keine eigenen SIP-Accounts zusätzlich zu den automatisch konfigurierten anlegen.

Das Ganze sollte dann ohne geänderte Firmware (also ohne Shell-Zugriff oder eigene Skripte - auch damit künftige Updates mitgemacht werden können) auskommen und glücklicherweise (in diesem Falle tatsächlich) stellt M-net den Kunden nur DS-Lite-Anschlüsse und damit natürlich auch einen AFTR bereit (IPv4 nur gegen den happigen Aufpreis von knapp 5 EUR/Monat oder beim "ganz großen Anschluß"). Die 7580 dahinter (eigentlich viel zu überdimensioniert und nur der Tatsache geschuldet, daß zum Zeitpunkt der Installation nur die 7590 und 7580 das neue FRITZ!OS 7 erhalten hatten) hat also gar keine IPv4-Konfiguration auf der WAN-Seite, die sie anstelle der IPv6-Abfrage des DNS benutzen könnte - sie ist auf "IPv6 only" und die Benutzung des AFTR von M-net konfiguriert.

Den DNS-Server lernt sie jetzt per RA (eben für die link-lokale fe80::/10-Adresse) von der 7430 (das war - neben den Einstellungen für "volles" DHCPv6 - die einzige wirklich relevante Änderung in der 7430) und dann kann sie ihn eben auch nutzen ... alles andere (statische vom Provider, keine RA) hat hier auch nicht funktioniert (zumindest nicht auf Anhieb und ohne Shell-Kommandos), weil die statischen Server (unter "DNS-Server" eingetragen) per RA überstimmt wurden ("showdslstat" zeigt an, woher der DNSv6-Server stammt - "dhcp" oder "ra") und die Box selbst keine Routen zu den DNS-Servern anlegte (wenn ich das jetzt nicht durcheinander bringe, das waren auch viele Versuche mit wechselnden Konfigurationen und Versionen und die 7390 mit 06.83 verhielt sich anders als die 7580 mit 07.00).

Damit konnte sie jedenfalls den DNS-Server nur erreichen, wenn die Standard-Routen dazu paßten ... und die Konfiguration der öffentlichen IPv6-Adresse der 7430 (natürlich der auf deren LAN-Seite) als DNS scheiterte daran, daß der IPv6-Präfix bei jeder Einwahl ein anderer ist und entsprechend getauscht werden müßte, was AVM (zumindest bei dem per RA verkündeten) nicht vorsieht (die 7430 von M-net hat irgendeine alte 06.83 als Firmware - das unterschiedliche Verhalten verschiedener FRITZ!OS-Versionen kam da noch erschwerend hinzu.

Gerade bei kaskadierten Routern (und IPv6) kommt man bei AVM wohl nicht daran vorbei (deshalb staune ich auch, daß jetzt so großzügig auf "IPv6 preferred" gesetzt wird bei 1&1), die DNS-Abfragen (sofern man keine fixen Server nutzen will, was aus Datenschutzsicht auch nicht das Gelbe vom Ei ist - die Diskussion dazu läuft ja gerade im Zuge von "DNS over HTTP") schön brav über die Kaskade abzuwickeln und dabei dafür zu sorgen, daß tatsächlich auch die Clients am Ende zuerst mal nach AAAA-Einträgen suchen (oder zumindest gleich parallel).

Dann arbeitet der "multid" von AVM (bzw. der von ihm gesteuerte "dnsd") schön brav als Forwarder (jeder mit seiner eigenen Ansicht, was in der Zone "fritz.box" so los sei - die kriegt man also immer schon vom ersten Resolver und kommt an die dahinter nicht mehr ran) und Cache und nimmt auf der LAN-Seite die Requests entgegen, die er auf der WAN-Seite (so er sie nicht bereits selbst beantworten kann aus seinen Zonen oder dem Cache) dann wieder an seinen Server stellt. Damit braucht es auch kein (IP-)Routing von DNS-Abfragen und für die Clients stellt sich gar nicht mehr die Frage, wen oder was die Box selbst abfragt - entscheidend sind die vom "dnsd" verwendeten Resolver.

Denn die FRITZ!Box braucht (zumindest in meinem Beispiel) eben auch ihre eigene "Weltsicht" ... das geht schon beim DynDNS-Account los (wo die kaskadierte Box bei meiner Aufgabenstellung erkennen mußte, daß sie keine eigene IPv4-Adresse hat, diese somit nicht aktualisieren und auch nicht immer wieder neu abfragen muß ... wobei ich auch bei der Angabe einer IPv6-Adresse für den DynDNS-Server in FRITZ!OS 7 krachend gescheitert bin, wenn ich mich richtig erinnere (aber nicht etwa schon beim Eintragen, sondern erst irgendwann später beim Parsen im entsprechenden Daemon), aber der entscheidende Punkt ist/wäre ohnehin die "Kontrolle" des "ddnsd" auf den Erfolg bzw. die Notwendigkeit eines Updates) und endet bei der Tatsache, daß der "voidp" (für den zusätzlichen SIP-Account, der hier der eigentliche Antrieb war neben der Sicherheit, daß der Provider nicht ins LAN (des kaskadierten Routers) sehen kann) grundsätzlich die DNS-Server befragt, die er auf der WAN-Seite gelernt hat - kommt er da nicht hin (z.B. eben wegen des Überschreibens des DNSv6-Servers per RA mit einer "fd00::/8"-Adresse, wie es in der Standardeinstellung (auch noch im FRITZ!OS 7) der Fall ist) wegen fehlendem Routing, kriegt man keine SIP-Accounts ans Laufen.

Insgesamt scheint mir die FRITZ!Box auch mit FRITZ!OS 7 noch zu unausgereift für den Einsatz am DS-Anschluß ... selbst wenn Kaskaden vielleicht nicht der primäre Einsatzzweck sind. Aber seitdem einige Provider mit der "Router-Freiheit" auch den Support generell verweigern möchten, sofern der Kunde eigene Endgeräte angeschlossen hat (und zwar vollkommen unabhängig davon, daß eine Leitungsunterbrechung ja i.d.R. nichts mit der Konfiguration zu tun hat), muß man m.E. immer öfter darüber nachdenken, solche Kaskaden zu bauen (bzw. ihre Verwendung zu empfehlen) - mal unabhängig von den zusätzlichen Stromkosten.

Wenn im Haushalt niemand lebt, der für den Support-Fall einfach mal den anderen Router anklemmen kann für die nächste Woche (und zwar inkl. Umkonfigurieren im LAN und bei der Telefonie - bis hin zur DECT-Anmeldung - man weiß ja nie, wie lange der Provider zur Fehlerbehebung braucht, wenn es keine Leitungsunterbrechung ist), werden die Kosten durch den zusätzlichen Stromverbrauch auch ganz schnell zweitrangig ... im Vergleich zu den Preisen, die der "durchschnittliche Dienstleister" für eine solche Umkonfiguration dann berechnen dürfte.

Damit ist und bleibt man entweder dem Provider hilflos ausgeliefert (inkl. möglicher Spionage über Fernwartungsfunktionen durch den Provider), weil man ausschließlich seinen Router verwendet oder man setzt den eigenen Router hinter den vom Provider und dann hat man genau dieses Szenario mit der Kaskade. Die meisten Kunden brauchen auch nicht wirklich etwas anderes als DS-Lite ... wenn sich IPv6-Adressen auch in den Mobilfunknetzen durchgesetzt haben, sind die Dienste der eigenen FRITZ!Box auch per IPv6 erreichbar und irgendwann wird AVM vermutlich auch mal IPv6 als Transport-Protokoll für das eigene VPN entdecken ... wenn das bei 07.00 noch nicht erfolgt sein sollte (ich hatte mal etwas in der Richtung irgendwo gelesen, weiß aber nicht, ob es tatsächlich bis ins Release gelangt ist).

Damit wäre dann so eine Konfiguration, wie ich sie eingerichtet hatte (das hier war in der Gegend von Hanau), immer öfter auch für Dienstleister eine denkbare (und dankbare) Lösung ... solange die kaskadierte Box korrekt konfiguriert ist, macht es am DS-Lite-Anschluß gar keinen Unterschied, ob ein Router an der Grenze des Heimnetzes sitzt (der vom Provider als Edge-Router) oder dahinter in einer Kaskade ... immer vorausgesetzt, die Präfix-Delegierung und die Port-Freigaben klappen im Edge-Router, was bei der 7430 auch nicht der Fall war, weil die Einstellung "exposed host" wirkungslos war und es tatsächlich nur mit den dynamischen Freigaben über PCP zwischen den FRITZ!Boxen sauber arbeitet.

Man verliert im kaskadierten Router aber nichts zusätzlich an Funktionen ... ja, bei einigen Sachen (wie eben dem DynDNS-Beispiel) ist es sogar deutlich von Vorteil, wenn der kaskadierte Router auch weiß, daß es sich um einen DS-Lite-Anschluß handelt. Also sollte AVM den Fokus auch etwas mehr auf die korrekte Funktion (und zwar mit Standardeinstellungen) in diesem Szenario legen ... und da gibt es noch einiges zu tun. Ich hätte vermutlich (ohne zusätzlichen Shell-Zugang, auch wenn der kein Dauerzustand sein soll) auch irgendwann den Bettel hingeschmissen ... das Ganze nur mit den Support-Daten zu untersuchen und dann noch das unterschiedliche Verhalten der letzten FRITZ!OS-Versionen (von 06.83 bis 07.00) können einem schon den Nerv rauben.

------------------------------------------------------------------------------------

Ich hoffe nur, daß AVM die Situation in künftigen Versionen tatsächlich verbessert (man darf auch mal die eine oder andere zusätzliche Einstellung einführen, wenn die vorhandenen bei der gestiegenen Zahl von Möglichkeiten das nicht mehr abdecken können) und nicht - wie bisher leider zu oft üblich - mit dem Hintern beim Umdrehen das wieder einreißt, was man vorne gerade aufgebaut hat und was die Kunden inzwischen auch verwenden.

Wenn bei solchen - etwas komplizierter "geborenen", nichtsdestotrotz funktionierenden und zwar ohne jeden "dreckigen Trick" - Konfigurationen nach einem Firmware-Update wieder mal etwas nicht geht, wird man die Kunden kaum für ein Update (und möglichst noch ein automatisches, wenn es nach den Hersteller-Empfehlungen geht) begeistern können ... und damit führt man seine eigene Informations- und Firmware-Politik ("Wir empfehlen grundsätzlich jedes Update auch aus Sicherheitsgründen.") gleich selbst ad absurdum.

Jedenfalls ist für mich - gerade bei einer FRITZ!Box als kaskadiertem Router - auch das derzeitige Verhalten des FRITZ!OS 7 indiskutabel ... so ein Router ist parallel auch immer ein Security-Device (vielleicht nicht immer ein gutes) und da sollte es schon eine Einstellung geben, ob der sich von irgendwelchen ND-Paketen auf seiner WAN-Seite (und die RAs gehören in diesen Kontext) dazu überreden läßt, einen anderen DNSv6-Server oder ein anderes Gateway zu benutzen. Die SLAAC-Mechanismen und ND sind ein Angebot und kein "must-have" ... wenn es statische Einstellungen gibt, kann es sinnvoll sein, diese per ND zu aktualisieren - oder eben auch nicht.

Wenn sich auf der WAN-Seite unsichere Geräte bewegen, die auch falsche RAs senden können, um den DNSv6-Traffic umzuleiten, dann kann die FRITZ!Box ja wohl kaum so einfach auch auf diese "hören" ... zumindest sollte man es ihr ausdrücklich verbieten können und dann muß man sich darauf auch verlassen können. Wenn sie die Einstellungen per DHCPv6 "gelernt" hat, dann muß sie diese auch verwenden ... im Extremfall kann man am besten sogar noch einstellen, welcher DHCPv6-Server als einziger "Vorgesetzter" zu akzeptieren ist (dann kann man ggf. sogar auf Broadcasts verzichten), um auch DHCP-Hijacking zu vermeiden. Die neueren Modelle mit ihrem zusätzlichen WAN-Port sind ja auch deutlich stärker auf den Betrieb hinter anderen Ethernet-Komponenten im Netz beim Kunden ausgelegt ... ob das nun ein externes Modem für DSL oder Glasfaser oder eben ein anderer Edge-Router ist. Da muß man dann auch mal zusätzliche Überlegungen dahingehend anstellen, was da von der Ethernet-Seite (am WAN-Anschluß) noch "nebenbei" kommen könnte.

Ansonsten wird die FRITZ!Box als Security-Device überflüssig, ja sogar gefährlich ... wenn mit der einfachen Konfiguration auch durch (relative) Laien immer weiter wachsende Unsicherheit durch undurchsichtige, unspezifizierte und undokumentierte Automatismen einzieht, tut sich AVM (nach meiner Ansicht jedenfalls) damit auch keinen Gefallen - weil zu den anderen Kröten, die man als Kunde inzwischen schlucken muß, immer mehr Skepsis ob der Sorgfalt beim Entwickeln und Testen kommt (und allzu oft wird Agilität vielleicht auch mit "funktioniert eben so wie es gerade fertig ist" verwechselt - das mag bei sicherheitsunkritischen Funktionen gelten und denkbar sein, ist bei security-relevanten Fragen aber ein absolutes "no go").

In dieselbe Kategorie gehört für mich auch die Feststellung, daß bei unkonfiguriertem Gerät die GRX-Boxen den WAN-Port einfach der Bridge mit den LAN-Ports zuschlagen ... es gibt bei AVM echte Vorkehrungen dafür, daß die Box aufgrund von Fehlern in den Einstellungen mit "Werkseinstellungen" startet (z.B. die Eventlog-Meldung mit der ID 60, die ich vor kurzem irgendwo in einer Liste hier veröffentlicht habe) und damit ist dann ein Netz hinter einer solchen Box, wo ansonsten der WAN-Port isoliert wäre mit der korrekten Konfiguration, jedem Zugriff von dieser Seite schutzlos ausgeliefert. Findet jemand einen Weg, eine FRITZ!Box zum "Vergessen" der Einstellungen zu zwingen, kann man damit auch einen bewußten Angriff fahren.

Warum geht AVM nicht hin und baut mit diesem WAN-Port in der Standard-Konfiguration (wenn das DSL-Modem aktiv ist) einfach eine echte DMZ auf? Dann schadet es auch nichts, wenn sich bei den Werkseinstellungen hinter diesem WAN-Port tatsächlich "das Internet" befindet ... der Zugriff auf die LAN-Ports ist trotzdem nicht möglich. Und AVM hat gleich noch etwas, was einige bisher schmerzlich vermissen ... nämlich eine "echte" DMZ, in der man auch eigene Dienste in einer Art und Weise betreiben kann, daß bei einem kompromittierten Server (und das passiert auch den Besten) nicht das gesamte LAN mit gefährdet wird, wie es bei einem "exposed host" nun mal der Fall ist. Ich verstehe auch noch, wenn man so einen Port nicht "brachliegen" lassen will ... aber das war schon mit dem LAN4 für das Gastnetz eher eine Schnapsidee, solange sich der Bootloader nicht dazu überreden ließ, von diesem Port keine FTP-Sessions zu akzeptieren. Das scheint (aus dem Kopf, aktuelle Tests müßte man noch mal machen) zumindest bei den GRX-Boxen und dem WAN-Port anders zu sein ... dort klappt zumindest das Suchen per UDP-Broadcast nicht, wenn ich mich recht entsinne.

Wobei mir dann auch gleich noch auffällt, daß bisher kaum thematisiert wurde, was AVM mit der 7590 auch noch bei jedem Update macht (zumindest mit der 06.92 und der 07.00 hat man es getan): Es gibt parallel zum Firmware-Update auch immer noch ein Update des Bootloaders ... geht man rein nach den Dateigrößen der jeweils enthaltenen Dateien "var/urladerupdate", ist das auch bei der 06.92 ein anderes als bei der 07.00 - wobei das auch auf die andere C-Library und das statische Linken dieses Programms zurückzuführen sein könnte. Der Inhalt (also der eigentliche Bootloader) könnte da immer noch derselbe sein ... bei der 7580 gibt es dieses Programm nicht, daher kann ich auch nicht einfach mal so nachschauen (bei der Ausführung), ob so ein Update tatsächlich mehrfach erfolgen würde oder wie weit es vorherige Prüfungen und Vergleiche gibt, ob ein Update überhaupt notwendig ist.

Die 7590 ist jedenfalls im Moment die einzige (mir bekannte) Box, wo AVM das mit dem "urladerupdate" (was in der "var/install" der anderen GRX-Boxen auch angelegt ist, wenn ich mich richtig erinnere) auch tatsächlich nutzt ... angesichts des doppelten Bootloader-Codes (wegen des NAND-Flashs) und der zusätzlichen Sicherheitsmaßnahmen (ich würde sagen, daß ein Update im finalisierten Zustand nur möglich ist, wenn tatsächlich beide Kopien des Bootloaders keine Fehler aufweisen ... das ist also nicht nur ein "blindes Überschreiben", wie es bei älteren NOR-Boxen teilweise geschah) sicherlich auch nichts, was man ohne echte Notwendigkeit machen würde - ich habe aber bisher noch in keiner "info.txt" etwas zu diesem Thema (hier wird die Box eben dauerhaft verändert, solange ein Recovery-Programm die Änderung am Bootloader nicht auch wieder rückgängig macht - DAS glaube ich aber nun tatsächlich erst, wenn ich es mit eigenen Augen gesehen habe) gefunden.
 
Zuletzt bearbeitet:
Wobei die Frage halt auch wäre, was hier die "statische Konfiguration" von Adressen ist, die Du meinst ... für die gesamten IPv6-Einstellungen oder nur für die DNS-Server?
Nunja, es gibt ja auch bei einer kaskadierten Box mehrere Eingriffsmöglichkeiten:
Die WAN-Schnittstelle per DHCP(v6) komplett selbst ihrer Konfiguration zu überlassen, oder ihre Adressen händisch zuzuweisen. Letzteres schließt die Angabe zu benutzender DNS-Server über die entsprechende Option unter "Zugangsdaten" genau so ein wie eine absolute statische Konfiguration für IPv4 und IPv6 unter den jeweiligen Settings der Protokolle. Letzteres dürfte nur für sehr spezielle Setups sinnvoll sein, da es grundsätzlich schon so ist, dass die Adresszuweisung per DHCP(v6) funktionell ist und auch IP-Wechsel ohne größere Probleme mitmacht. Ich konnte bis jetzt jedenfalls keine erheblichen Einschränkungen meiner Clients in diesem Setup feststellen.
Der geschilderte Betrieb der 7590 als WAN-Client hinter der 7490 resultiert übrigens primär aus dem Vorsatz, hinter der 7490 ein weiteres "fremdes Heimnetz" haben zu können, das in meinem Fall von einer 7390 (ebenfalls als WAN-Client) bereitgestellt wird. Diese Netze sollen sich weder "sehen" noch miteinander kommunizieren können. So ganz nebenbei ist dies auch ein Tip für diejenigen, die sich über Konflikte mit Fritten als IP-Clients und deren "Gast-Netzen" beschweren. Die konsequente Trennung der Sub(-)Netze düfte so manchen Stress in Luft auflösen und stellt nebenbei Sicherheitsbereiche zur Verfügung, sofern sie gewollt und sinnvoll sind.
Insgesamt scheint mir die FRITZ!Box auch mit FRITZ!OS 7 noch zu unausgereift für den Einsatz am DS-Anschluß ... selbst wenn Kaskaden vielleicht nicht der primäre Einsatzzweck sind.
Das ist glücklicherweise auch kein Problem. Ich bin Telekom-Kunde und somit bei einem Anbieter, der IPv6 als einer der ersten mit anbot. Das Protokoll ist längst nativ am Anschluss verfügbar, während andere entweder immernoch nur 6to4 oder eben DS-Lite anbieten, was das eine oder Problem aufwirft, wenn es um mehr als das reine Surfen geht.
Aber zurück zum eigentlichen DNS-Problem und deiner Frage
warum die FRITZ!Box selbst auch über das PiHole gehen soll. Die macht ja eher keine unerwarteten DNS-Abfragen wg. irgendwelcher eingebetteten Werbung in HTML-Seiten oder ähnliches ... die "Ziele" ihrer selbstinitiierten Kommunikation im Internet sind einigermaßen vorbestimmt und da greift man entweder ein, indem man die abfragenden Dienste stilllegt oder man läßt es gänzlich sein
Im Grunde magst du Recht haben, aber es gibt auch nichts, was dagegen spricht. Und mittlerweile traue ich AVM auch nur noch eingeschränkt über den Weg. Zwei Beispiele:
Ich schleiche mit meinem Notebook über die Konfig-Seiten meiner 7590 und finde im Pihole einen DNS-Request des Notebooks nach www.avm.de. Was bitte soll das? Ich weiß zwar anhand des DNS-Requests nicht, was für Daten da ausgestauscht werden sollten, allerdings ist nicht anzunehmen, dass der Rechner ohne erkennbaren Grund nach einer Kontaktaufnahme strebt. Da ich ansonsten keine AVM-Software benutze und auch keine Dienste wie MyFritz o.ä. benutze, liegt hier der Verdacht nahe, dass in der Firmware der Box etwas eingebettet ist, was die Kommunikation auslöst. Ich müsste dazu allerdings mal den Traffic mitschneiden, was ich noch nicht getan habe.
Ebenfalls merkwürdig erscheint mir die Öffnung der Ports 61000 und 61001 per UPnP in der vorgelagerten 7490. Laut der 7590 stammte diese Anforderung nicht aus meinem Heimnetz. Was über diese Ports kommuniziert werden soll? Keine Ahnung! Die Netzrecherche lieferte Antworten von einem Backdoor bis zu einem regulären Systemdienst. Für beides gab es aber keine Anhaltspunkte.
Aber ich habe noch einen RPi herumliegen, den ich bei nächster Gelegenheit in das vorgelagerte Heimnetz integrieren kann, um auch dem Phänomen noch auf die Spur zu kommen und die Suche nach unerwünschtem Datenaustausch mit dem Hersteller meiner Hardware einschränken zu können.

Dass die Firmware sich hartnäckig weigert, andere DNS-Server als nur den vorgelagerten Router zu benuzten, ist auf jeden Fall eine fragwürdige Erscheinung, die sich noch nicht einmal mit VoIP erklären lässt. Die kaskadierte 7590 macht zwar tatsächlich auch den Telefoniekram, "weiß" also, dass sie Telekom-Client ist, aber die DNS-Server benutzt sie deshalb auch nicht.
 
hausgemachte "Bugs" wie das Thema Portfreigaben
Au ja, dank Mesh oder was auch immer, verweigerte mir jetzt eine zweite 7590 im selben Subnetz an einem zweiten ADSL-Anschluss eine neue Portfreigabe zu einem PC, weil dessen IP schon der 1. Box bekannt ist, und nein nicht per AVM-DHCP vergeben, das machte ein gesonderter Server.
 
Das Fritz!OS 7.00 auf eine fabrikneue 7590 (mit 6.90) zu spielen kann auch ein Schockerlebnis werden: Box heute ausgepackt, das frisch geladene Image per WebIF in die Box geladen und dann bin ich 10 Minuten geduldig vor der blinkenden Kiste sitzen geblieben. Da war dann wohl etwas schief gelaufen. Letztlich blieb mir nur, mutig den Stecker zu ziehen, was ich allerdings auch gleich genutzt habe, um die Firmware per Recoverytool zu flashen. Glück gehabt: Hinterher hatte ich Fritz!OS 7.00.
Nach dem Einrichten konnte die Box ans Netz und siehe da: Ein aus den Labors bekanntes Bild taucht wieder auf: Der Schrägschnitt im Spektrumdisplay! War das nicht schon mal behoben?
Saegezahn.png
 
Den Schrägschnitt habe ich neuerdings auch.Fritzbox 7590 noch mit alter 6.92 FW.
Vor 2 Tagen über Nacht ein Update auf Broadcom 192,26 erhalten.

Vorher war die Anzeige normal, jetzt halt mit Schrägschnitt.

Leitung bisher soweit stabil mit gelegentlichen Resyc.
wenn es so bleibt bin ich zufrieden
 
Unnötiges Vollzitat von darüber entfernt

Hab diesen Schrägschnitt schon seit ich auf die 7590 während der Beta-Phase gewechselt bin. Ist bislang auch geblieben. Hier auch der Broadcom 192.26 im Kasten verbaut.


//edit by stoney: automatisierte TapaTalk Signatur entfernt
 
Zuletzt bearbeitet von einem Moderator:
Schräge Anzeige (FB7590 mit 6.92 und 7) seit Broadcom 177.218 -> Broadcom 192.26

Servus,

Winnie
 
Kann eigentlich das TAE Kabel für seltene Sync Verluste mit verantwortlich sein, wenn die Leitung im Grunde eigentlich optimal ohne Fehler läuft? Ich hab irgendwann mal n kürzeres NO-Name Kabel gekauft, um so ein bisschen Kabelsalat zu vermeiden. Ich habe nämlich mit der Version 7.0 an einem Broadcom 177.191 Verteiler ebenfalls gelegentliche Verbindungsabbrüche...
 
Kann eigentlich das TAE Kabel für seltene Sync Verluste mit verantwortlich sein
Ganz ausgeschlossen ist das nicht, ich halte es aber auch nicht für extrem wahrscheinlich. Früher™ gab es hin und wieder mal Probleme mit angegammelten TAE-Dosen, die sich durch Kracher in der analogen Telefonie bemerkbar machten und damit auch DSL störten. Die musste man dann einfach mal wechseln lassen. Mit einem konventionellen Telefon lässt sich ein solches Szenario heute allerdings nicht mehr identifizieren, da es keinen Schleifenstrom mehr gibt.
Einzige Möglichkeit ohne spezielle Messtechnik ist wohl, die Spektrumanzeige zu beobachten und die beiden Kabel zu vergleichen. Sollten sich mit dem einen erhebliche Einbußen in bestimmten Frequenzbereichen zeigen oder Sprünge in der Signalstärke, dann ist es sicher ungeeignet.
Ansonsten besteht noch die Frage, ob die Abbrüche zu bestimmten Zeiten gehäuft auftreten. Ich musste schon die BNetzA anrücken lassen, weil ein extrem starkes Signal hier DSL störte. Ich hatte den Störer schon ausfindig gemacht, weil er bis weit über 30 MHz Schaden verursachte und vor seinem Stromzähler mein Empfänger in der Hand "zitterte".
Ursache war ein Satellitenreceiver, dessen Netzteil defekt genug war, das zu leisten, der aber dennoch funktionierte, sodass der Besitzer von dem Spuk nicht bemerkte. Nach Blitzeinschlägen haben auch schon die EDV-Anlagen zweier Firmen in meiner Stadt das Telefonnetz so sehr gestört, dass ich mit dem Breitbandempfänger auf die Suche gegangen bin und die Leute angesorochen habe. Auch sie haben zunächst nichts bemerkt und sich auch um nichts kümmern wollen. In diesen Fällen habe ich jeweils Telekom-Techniker mobilisiert.
Die Suche nach Heimgeräten, u.a. auch Beleuchtungseinrichtungen mit sog. Schaltreglern kann also hilfreich sein, wenn eine zeitliche Korrelation besteht. Selbst von eigenen Haus entfernte Störer sind nicht ausgeschlossen.

Schräge Anzeige (FB7590 mit 6.92 und 7) seit Broadcom 177.218 -> Broadcom 192.26
Aha. Ich kannte das bisher nur aus den Labors der 7490, wo das allerdings mitllerweile behoben wurde. Meine bisherige 7590 hatte noch nie ein DSL-Signal gesehen, daher war ich doch recht erstaunt. Hier übrigens auch mit Broadcom 192.26.
 
Zuletzt bearbeitet:
Bei mir gibt es auch sporadische Resyncs, die letzte war allerdings schon am 6.8., obwohl die Störabstandsmarge meiner 7590 noch nie unter 14 dB lag. Der TAE-Anschluss ist bei mir seit Jahren ersetzt durch eine passende CAT.5e-Dose (was LSA+-Klemmen und RJ45-Goldkontakte bedeutet) und das zu kurze Original-TAE-Kabel durch ein schönes langes Patchkabel. Bei den möglichen Störquellen sind bei mir LED-Leuchtmittel (stören z.T. sogar schon Kabel-TV) als Kandidaten hinzugekommen. Ansonsten halte ich die verbliebenen Analogleitungen mit ihren perversen Klingelspannungen und unsere lieben Router-Ausschalter immer noch für die größten Vectoring-Feinde.
 
Ich hatte den Störer schon ausfindig gemacht, weil er bis weit über 30 MHz Schaden verursachte und vor seinem Stromzähler mein Empfänger in der Hand "zitterte".
Man mag ja kaum glauben, dass der Sat-Receiver völlig problem funktionierte. Was für ein leichtes Empfangsgerät benutzt Du ;-)
 
Danke für die ausführlichen Antworten.

Ich hatte über Jahre einen konstant funktionierenden 50 Mbit/s Anschluss mit sehr guten Leitungswerten. Seit der Umstellung auf Vectoring kommts halt zu unterschiedlichsten Tageszeiten zu Sync-Verlusten; war auch bei der Vorgängerbox, einer 7490 so; mal ist 2 Tage alles gut, mal 3, dann mal 10, dann mal nur 12 Stunden.

Der Router steht abseits anderer technischer Geräte, ein Raspberry Pi steht direkt daneben, das wars aber auch...
 
Für alle die sich für das schräg abgeschnittene Spektrum interessieren hier der dazugehörige Thread:
https://www.ip-phone-forum.de/threads/fb7490-komisches-spektrum-was-kann-das-sein.299524/

(Dieser Anzeige-Bug in FRITZ!OS ist modellübergreifend, betrifft also nicht nur die 7590 oder 7490.)


Dieser Bug ist schon sehr lange in FRITZ!OS enthalten, also war auch schon lange vor FRITZ!OS 6.9x oder 7.0x vorhanden. Ist halt nur nie aufgefallen da bisher wohl kaum eine Linecard bei VDSL mit Profil 17a wirklich alle 4.096 Träger bis zum Ende verwendet hatte, auch nicht die Linecards mit Infineon-Chipsatz (obwohl die am Ende mehr Träger verwendeten als die Linecards mit Broadcom-Chipsatz, aber alle eben auch nicht).

Huawei-DSLAMs nutzen nun mit der neuesten Linecard-Software (Ver. 192.26) tatsächlich zum ersten Mal das gesamte verfügbare Spektrum bei Profil 17a, dadurch ist dieser Bug wohl überhaupt erst aufgefallen. Gefixt wurde dieser Bug wohl mit der Ver. 06.98-60092. Da die 7.00 Release (de) der 7590 allerdings noch die Buildnummer 59666 hat ist hier der Bugfix noch nicht enthalten.
 
Hallo Zusammen,

nachdem ich seit einigen Wochen drei-vier Resyncs habe, sowohl mit der 06.92 als auch mit der 07.00, habe ich am Donnerstag meine 7590 per Recover erneut auf die 07.00 gebracht und alles neu konfiguriert.

Ich habe nach wie vor Abbrüche bzw. Resyncs, obgleich sich meine Vorortgegebenheiten (Verkablung usw.) nichts geändert haben.

Ich habe die folgenden Meldungen im Ereignislog:

Fehler bei der DSL-Übertragung (CRC-Fehler). Der Fehler wurde möglicherweise durch Powerline verursacht.
Das DSL-Signal wird möglicherweise durch Powerline gestört.
Internetverbindung IPv6: AFTR konnte nicht bezogen werden: Grund 7 (got no aftr)
IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2001:16b8:22:8a00::/56
Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: xxxx:1xxxx:1xxxxx1:exxxx:6dff:fe75:d428
Information des Anbieters über die Geschwindigkeit des Internetzugangs (verfügbare Bitrate): 109341/40000 kbit/s
DSL ist verfügbar (DSL-Synchronisierung besteht mit 109341/41998 kbit/s).
DSL-Synchronisierung beginnt (Training).


Ich habe aber gar kein Powerline im Einsatz und laut heutige Info von 1&1 Hotline ist bei meinem Anschluss DS-Lite deaktiviert.

Kann von Euch Fachleute mal über die Screenshots schauen ob Euch etwas auffällt, ich habe in den letzten 4 Wochen schon zwei Mal bei 1&1 angerufen und die meinten alles ist ok. Auch die Leitung wurde bereits ohne Beanstandung gemessen.

Ich frage mich nur was die 3-4 Resync bzw. Abbrüche pro Tag auslöst.

Bei der Neukonfiguration der DECT-Telefone ist mir ein Bug aufgefallen, den ich vor längerer Zeit gereits auf der 7390 hatte. Beim umbenennen eines Schnurlostelefon z.B. von "Mobiltelefon 1" auf "Küche" funktioniert dieses nicht, die Eingabe übernimmt keine Umlaute, also heißt das Telefon jetzt "Kueche".

Vielen Dank
Navy
 

Anhänge

  • DSL-Information.PNG
    DSL-Information.PNG
    44.6 KB · Aufrufe: 66
  • DSL-Spektrum.PNG
    DSL-Spektrum.PNG
    90.2 KB · Aufrufe: 65
  • DSL-Statistik.PNG
    DSL-Statistik.PNG
    41.2 KB · Aufrufe: 65
  • DSL-Verbindungseigenschaften.PNG
    DSL-Verbindungseigenschaften.PNG
    67 KB · Aufrufe: 67
Ich habe aber gar kein Powerline im Einsatz

Wohnst du vielleicht in einem Mehrfamilienhaus? Falls dort die Nachbarn Powerline nutzen, kann das deine Leitung ebenfalls beeinflussen - allerdings dürfte der Nachbar (sofern er auch VDSL Vectoring nutzt) noch mehr Probleme haben. Hier ein Beispiel, was Powerline auswirken kann: https://www.onlinekosten.de/forum/showthread.php?p=2445992#post2445992

ist halt wie ein externer Störer - ich würde einen Techniker kommen lassen, der die hohe Fehlerrate mit dem Argus feststellen kann. Ist die Leitung ansonsten in Ordnung, muss die Suche nach dem externen Störer erfolgen, notfalls mit Hilfe der Bundesnetzagentur. Powerline ist eine echte Seuche in Kombination mit Vectoring.
 
Hallo Eifelman,

Nein, ich wohne in einer Doppelhaushälfte, also eine Stromversorgung.
Ich habe jetzt die "Störsicherheit" mal auf maximale Stufe gestellt denn meine 7590 hat gerade wieder einen Resync hingelegt.
1&1 hat ja heute Morgen die Leitung gemessen und alles für gut befunden.
Vielen Dank für Deine Tipps

Gruß
Navy
 
Beim umbenennen eines Schnurlostelefon z.B. von "Mobiltelefon 1" auf "Küche" funktioniert dieses nicht, die Eingabe übernimmt keine Umlaute, also heißt das Telefon jetzt "Kueche".
Was hast du für ein Mobilteil? Ich hatte das früher bei einem Gigaset A24, aber da lag es daran, dass die Segmentanzeige keine Umlaute konnte, bei meinen A400 geht das problemlos...
 
hast du schon mal die Option "Vorherige DSL-Version verwenden" gesetzt ??
Die ist unter Störsicherheit zu finden
 
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.