Warum ist dein Vertrag denn gekündigt? Wenn er nicht gekündigt ist, dann tu einfach gar nichts, weil dann verlängert er sich ja nur noch mit einer Kündigungsfrist von 1 Monat.
Beiträge von frank_m
-
-
Was dann zum Problem wird, weil die Kameras offenbar kein IPv6 unterstützen. Aber warten wir es ab.
-
Etwa 2,5h ohne IPv6. Wäre nett, das ebenfalls bei DG zu bemängeln.
Ich glaube nicht, dass das Sinn macht.
Wenn man die DHCP Lease Times bzw. die DHCP-Request Intervalle der Fritzbox in Betracht zieht, dann passt das exakt zu meinem Ausfall. Die haben also schon bemerkt, dass da was nicht passte. Was soll eine Störungsmeldung bringen für eine Störung, die behoben ist und auf den offiziellen Kanälen erfasst wurde? Die Leute da haben besseres zu tun.
-
Ich hab im Laufe des Vormittags einige Messungen gemacht. Auf die Bandbreite und auf den Ping hatte die Änderung keinen Einfluss.
-
Kaum zu glauben, aber wahr, ich hatte gestern die gleichen Meldungen im Log:
Code
Alles anzeigen22.10.22 08:13:48 Internetverbindung wurde erfolgreich erneuert. IP-Adresse: 100...., DNS-Server: 185.22.44.50 und 185.22.45.50, Gateway: 100.... 21.10.22 22:14:26 IPv6-Präfix wurde erfolgreich aktualisiert. Neues Präfix: 2a00:6020:... 21.10.22 21:55:41 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:... 21.10.22 21:55:41 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a00:6020:... 21.10.22 19:48:26 Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 () 21.10.22 19:44:20 Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL) 21.10.22 19:43:06 Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 () 21.10.22 19:38:43 Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL) 21.10.22 19:29:03 Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 () 21.10.22 19:25:19 Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL) 21.10.22 19:25:03 Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 () 21.10.22 19:24:48 IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out) 21.10.22 19:24:48 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.Habs aber erst heute morgen gesehen. Wahrscheinlich hab ich es nicht bemerkt, weil die IPv4 Verbindung bestehen blieb. Ich hab zu der Zeit Streaming Dienste benutzt.
Was noch viel interessanter ist, ich hab nun ein komplett anderes IPv6 Prefix als vorher. Meine IPv6 Adresse und das Prefix passten immer noch zu dem alten Schema, dass hier im Forum auch mal erläutert wurde, wo man anhand der IPv6 Adresse das Prefix "berechnen" konnte. In vielen Anschlussbereichen ist das ja inzwischen anders, nun auch bei mir. Das heißt für mich, dass es hier definitiv Änderungen in der Infrastruktur gegeben hat, vielleicht in der Software der DHCP Server.
Wie dem auch sei, der erste Ernstfall für meine DynDNS Infrastruktur. Ich betreibe einen eigenen dyndns Server auf einem VPS, der dann die Einträge weiterverteilt an andere dyndns Dienste, um Redundanz zu haben. Diese anderen Einträge werden dann wieder von Überwachungsscripten getrackt, ob auch alle Daten angekommen sind. War bei einem nicht der Fall, somit hatte dieses Event am Ende soagr noch was gutes.
IPv6 Prefixes ändern sich bei mir nämlich nur äußerst selten. Seit Schaltung des Anschlusses Ende 2017 hatte ich zunächst den DG ONT mit einer 7490 im Einsatz, da gabs dauerhaft das gleiche Prefix. Geändert hat es sich im Februar 2021, als ich die 5530 in Betrieb genommen habe. Nun wieder, und das erste Mal ohne Endgerätewechsel.
-
Ok, dann hat sich der Verdacht erledigt. Dann liegt es meines Erachtens an der DHCP Infrastruktur.
-
Auch nicht besser. Den DHCP Offer bekommt man von einer 100er Adresse. Die MAC Adresse ist die gleiche, von der auch die IPv6 RAs kommen.
Für die DHCP Meldungen der Fritzbox scheint zu gelten, dass mindestens 12 Stunden und 1 Sekunde vergangen sein müssen, bevor eine neue Meldung im Log auftaucht. Wenn man Pech hat, ist die DHCP Transaktion zu früh fertig, und die nächste ist dann erst 30 Minuten später. Im Anhang ist ein Bild, wo ich mit grünen Pfeilen einige DHCP Updates mit 12 Stunden + 1 Sekunde markiert habe, und mit roten Pfeilen den Fall, wo sich die Sekunde nicht erhöht hat und folglich 12:30 seit dem letzten Eintrag vergangen sind.
Aber richtig ist, dass die alle 30 Minuten stattfinden. Bei DHCPv6 sind es alle 18,75 Minuten (1125 Sekunden, halbe Preferred Lifetime).
Ich hab den ganzen DHCP Traffic der DG schon mal ausführlich auseinandergenommen und auch die entsprechenden Wireshark Pakete gezeigt. Ich müsste den Post noch mal raussuchen. Aber eins ist sicher: 10er Adressen haben da nichts verloren. Deshalb ist mein Verdacht, dass schon lange vor DHCP was schief geht.
-
Du schreibst in deinem einen Dokument, dass du ein DHCP-Offer für 10.124.1.24 bekommen hast. Das ist ja das völlig falsche Netz. Aus dem 10er Netz bekommen diejenigen eine IP, die im GPON Onboarding Prozess sind und den Aktivierungscode benutzen wollen. Bist du sicher, dass deine physikalische GPON Verbindung stabil stand zu dem Zeitpunkt?
-
Wie möchtest du die UDM denn betreiben? Hinter dem ONT? Dann benötigst du den Aktivierungscode nicht.
Generell arbeitet IPv4 einfach mit DHCP und IPv6 mit RAs und DHCPv6 (Adresse und Prefix).
-
Üblicherweise wird die Nachricht von weiteren Meldungen begleitet, wie DHCP Fehler oder ähnliche. Ist sowas zu sehen?
-
So vollkommen ohne Info über die verwendete HW ist das schwierig. Welche Fritzbox? Wie ist der Traffic Shaper eingestellt? Wie ist die Anbindung zum ONT organisiert? Sind alle Schnittstellen auf voller Geschwindigkeit? Nutzt du WLAN? Oder DLAN? Warum sind es 2 Fritzboxen und nicht nur eine?
-
Ja, das ist blöd, da stimme ich zu. Wie gesagt, eine einfache Lösung sehe ich für DHCP nicht, da dem Protokoll da einfach einige Features fehlen, wenn man keine Klimmzüge bauen will.
-
Ich hab zz. keine Chance mein Heimnetz von außen zu erreichen - nicht mal mit Portmappern. Gibt es andere Lösungen?
Ja, es gibt die VPS Lösung. Die kleinsten verfügbaren VPS bei IONOS oder Netcup reichen schon. Du baust einen Tunnel dahin auf und machst darüber dein Heimnetz erreichbar. Dazu findet sich schon einiges hier im Forum, Details gern in den passenden Threads.
-
Versuchs mal mit einem manuellen Neustart über die Weboberfläche ...
(sorry, den konnte ich mir nicht verkneifen).
-
Wenn ein Kunde dann meint, sich beschweren zu müssen, weil er eine Adresse nicht verwenden kann, die vom DHCP-Server für die noch nicht abgelaufene Leasetime zugeteilt wurde, vermittelt man freundlich, dass die "ein Gerät direkt am Anschluss" Regel über der DHCP-Lease steht.
Ja toll, dafür müsstest du ja die alte IP irgendwie blockieren, in der Firewall oder so. Eine Sonderlocke nach der nächsten, da dafür wieder eine Verbindung zwischen DHCP Server und Firewall gestrickt werden müsste, die es eigentlich nicht gibt.
Da sehe ich schon wieder 1 Millionen Verbindungsabbrüche auf uns zukommen, zu der wir dann schreiben, "ja da hat sich das System wohl geirrt und deine IP gesperrt. Warum auch immer". Auch nicht besser, als jetzt.
Und wofür? Wie oft kommt das denn vor? Eigentlich ja nur beim Routerwechsel. Wenn die Anfrage von der selben MAC kommt, dann kriegen es die DHCP Server ja üblicherweise hin, die Session richtig zuzuordnen. Fehler kommen zwar vor, aber eher selten. Und deshalb so ein Risiko? Nee. Ich würde es nicht machen.
-
Die Provider sollen ja auch nicht mehrere Leases zuteilen, sondern entweder die Lease ungültig machen ...
Was ja eben so einfach nicht ist. Das Endgerät geht davon aus, dass es die zugewiesene Adresse für die genannte Zeit nutzen kann und wird das möglicherweise auch tun. Ein DHCP Release ist im DHCP Protokoll zwar seitens des Clients vorgesehen, aber nicht seitens des Servers.
... oder einfach dem Anschluss wieder die alte Lease zuteilen, egal ob da jetzt ein neuer Router dranhängt oder nicht.
Was IP-Address Konflikte erzeugen kann, und dann geht gar nichts mehr, weder am neuen noch am alten Router. Auch nicht schön.
DHCP ist für diesen Fall schlicht nicht gut geeignet, da es dem Server nicht erlaubt, einen Client gezielt rauszuwerfen. Das einzige, was man Serverseitig machen kann, ist das Zulassen neuer Clients zu verhindern. Voilà.
Ergo: Lasst den Client dem Server mitteilen, dass er die IP nicht mehr braucht. Geht bei Fritzboxen leider nur durch den erwähnten Neustart.
-
Naja, wir alle kennen die Gründe, warum die Provider zurückhaltend mit dem Verteilen neuer Leases sind, und die sind ja auch berechtigt. Bei PPPOE hab ich aufgrund des fehlenden Handshakes sofort die Möglichkeit, das zu erkennen und so eine Mehrfachnutzung auszuschließen. Die fehlt bei DHCP. Es ist ja auch nicht die Lease Time das Ausschlusskriterium. Bei der DG wird die IPv4 Adresse ja auch nur alle 12 Stunden erneuert, dennoch bekommt man im Zweifel nach 1 Stunde eine neue Adresse.
Bleibt die Frage, warum der DHCP Server die Anfrage als neu interpretiert hat und nicht erkannt hat, dass sie vom gleichen Gerät wie vorher kommt. Das müsste man sich halt anschauen. Aber die State Machines von DHCP Servern sind empfindlich, das bekommen auch regelmäßig die zu spüren, die über DHCP zuverlässig feste IP-Adressen verteilen wollen. Die Foren sind voll davon, auch von Fritzbox Nutzern.
-
Und wie genau sollte ich den richtigen Zeitpunkt beim Neustart des Steckerziehens erkennen? Wenn alle LED's kurz angehen?
Ja, genau, daran erkennt man es zum Beispiel. Oder halt an den typischen Blinkfolgen in der Bootphase.
Der Punkt ist halt, dass die Box das DHCP Lease freigibt, wenn sie herunterfährt. Das erspart einem auch die 1 Stunde Wartezeit bei der DG beim Routerwechsel. Klar mag die Realität häufig eine andere sein, aber es funktioniert, und ist auch keine Überraschung, wenn man sich mit der Arbeitsweise von DHCP befasst. Wenn der Server glaubt, kein Lease mehr für einen spezifischen Anschluss zu haben, dann wartet man halt bis zum Ablauf des alten Leases. Bei der DG ist das eine Stunde, bei OI offenbar länger.
Alternativ kannst du natürlich das Steckerziehen mit dem Ablauf des DHCP Leases koordinieren. Aber ob das am Ende komfortabler ist ...
Übrigens wird genau das auch bei Hiddensee passiert sein. An ein Eingreifen des Supports glaube ich da auch nicht. Irgendwann gabs ein Lease, und ab da ging es.
-
Es wurde ausdrücklich vereinbart das man sich an mich wenden solle.
Ja, und wenn du als Handwerker unterwegs warst, dann weißt du, dass du in 99% aller Fälle durch den Mieter in eine Mietwohnung gelassen wirst, und nicht durch den Eigentümer.
Auf dem Zettel des Handwerkers stand "Sprich dich da mit jemandem ab". Es öffnet eine Dame die Tür, die offensichtlich über die Baumaßnahme informiert war, aber ansonsten offensichtlich nicht instruiert wurde (=> Eigentümer benachrichtigen). Sie sagt "jaja, passt alles, hier müssen Sie arbeiten." Was würdest du als Handwerker machen? Und sei mal ehrlich zu dir selber und komm jetzt nicht mit "Aber es war anders abgesprochen".
Generell ist die Situation nun mal so, wie sie ist, und du hast ein Interesse daran, dass sich das ändert. Den Handwerkern und dem Glasfaserunternehmen ist das egal, die können ihre Leistung erbringen. Und wenn du sie daran hinderst, dann halt nicht, aber den Ärger und den vermurksten Anschluss hast du im Keller, nicht sie. Und ob du ein Betretungsverbot ausgesprochen hast, das interessiert sonstjemanden, wenn die Mieter die Tür öffnen. Das solltest du nicht vergessen, bei all den Entscheidungen, die du in deiner Wut nun triffst.
Ja, du kannst auf deinem Recht beharren und behältst den Pfusch im Keller. Oder du gehst konstruktiv an die Sache ran und hast zumindest eine gewisse Chance, dass es korrigiert wird, und das du am Ende sogar noch zu deinem Anschluss kommst.
-
Gestern musste ich mal für einige Zeit das Steckernetzteil der FritzBox ziehen wegen Umbauarbeiten.
Du hast einfach den Stecker gezogen, ohne die Box herunterzufahren (bzw. einen Neustart anzustoßen)? Dann hatte der DHCP Server noch einen gültigen Lease für deine Box. Möglicherweise hat er eine neue Adresse erst nach Ablauf des Leases herausgerückt, warum auch immer.
Versuche das nächste Mal, die Box neuzustarten (übers Webfrontend) und den Stecker erst zu ziehen, wenn du anhand der LEDs erkennt, dass die Box den neuen Boot beginnt.