Skip to main content
Warum O2
Warenkorb
Service

Moin zusammen,

ich habe seit einiger Zeit (min. seit 26.08.) das Problem, dass meine FritzBox 6660 Cable (Version 7.57, gemietet, Tarif myHome XXL) nach erfolgreichem Aufbau der physischen Internet-Verbindung (“Kabel Internet ist verfügbar”) ca. 18 Minuten auf eine IP-Adresse wartet (Fehler: Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)). In dieser Zeitspanne habe ich weder Telefonie noch Internet noch lokales Netz. Anschließend erhalte ich dann sowohl eine IPv6-Adresse als auch eine IPv4 über DS-Lite und die Verbindung ist dann (toi, toi, toi) bis zur nächsten Trennung stabil und performant.

Das Ganze spielt sich reproduzierbar nach einheitlichem Muster mit vergleichbaren Zeitspannen gemäß Ereignisanzeige ab:

Beim ersten dbzgl. von der Hotline geöffneten Ticket sollte eine Großstörung ursächlich sein, was jedoch nicht der Fall war (Störung beseitigt, Problem ist geblieben). Das zweite Ticket wurde mit dem Hinweis geschlossen, dass das Problem in meinem WLAN liegen müsse und ich erhielt diesbezügliche Optimierungshiweise, die sicherlich fürchterlich wertvoll sind, nur in der Sache wenig hilfreich, da das Problem ja die Verbindung zwischen Router und Provider-Gateway betrifft, die herzlich wenig mit dem WLAN zu tun hat. Der Vollständigkeit halber sei erwähnt, dass auch der gute alte Werksreset nicht geholfen hat.

Eine Sache, die mich stutzig macht, sind die Verbindungseinstellungen unter IPv6: Dort ist "Globale Adresse automatisch aushandeln" ausgewählt, obwohl die (vermutlich nicht grundlose?) Erläuterung des Eintrags unmittelbar darunter "Globale Adresse ausschließlich per DHCPv6 beziehen" besagt, dass Letztere zu wählen sei, "wenn Sie eine Internetverbindung über TV-Kabel nutzen". Versuch würde klug machen, nur leider werden die Einstellungen auf dieser Seite nach Änderung stets Provider-seitig überschrieben.

Hat jemand eine Idee, wer/wie man dieses (zumindest lästige) Problem angehen kann, denn das war definitv mal anders und dauerte max. 2-3 Minuten? Danke und VG!

In dem Kontext noch eine Info: In den Ereignismeldungen hatte ich zuletzt auch gehäuft die Meldung: „DNS-Störung erkannt, Namensauflösung erfolgt über öffentliche Server“.

Diese Meldung ist für mich auch ein Indiz, dass mit der O2-Kopfstelle ein grundsätzliches Problem vorliegt. Am 02.11. habe ich für mich die Konsequenzen gezogen und in der FB einen Alternativen DNSv6-Server (quad9) eingerichtet (und JA, Telefon funktioniert problemlos).

 

 

 

 


Was interessant waere, ist ein Packetcapture der WAN Seite der Fritzbox waehrend der Problemphase...


Was interessant waere, ist ein Packetcapture der WAN Seite der Fritzbox waehrend der Problemphase...

Here you go,

zuerst filtriert auf DHCPv6 protocol:

 

eine router Solicitation und gaaaanz viele Router Advertisements (davon gibt’s mehr, nur die ersten “fotografiert”):

 Gab’s auch eine Menge “Neighbor Solicitation” die ich excluded habe


Danke. Bei DSL/FTTH Anschluessen gibt es bei O2 momentan manchmal das Phaenomen, dass eine nicht RFC-konforme Adresse die Antwort sendet und viele Router solche Adressen gar nicht durch die Firewall lassen, aber so sieht das hier erstmal nicht aus...


Danke ​@pufferueberlauf0 ,

ich habe auch die  Adresse  0:80fe: gesucht, nicht gefunden.

Man kann nur sehen  den Zeitunterschied: SOL (23:48) → Advertise/Reply (00:06).

Falls Du noch Ideen hast, oder weitere Infos brauchst, bitte melde Dich.


@mr.colombo 

Bei mir das Gleiche:

Gestern 4 Stunden DNS-Störung, heute schon wieder seit mehr als 2 Stunden.

 

Gruß

Dithmarscher1982


Da ich das “Öffne Ticket, schließe Ticket”-Spiel leid bin, bin ich jetzt auch über die Bundesnetzagentur gegangen. Ob’s etwas bringt, wird sich zeigen.


@deepthought4271 Wieviele Tickets waren es denn?
Konnte die Hotline Dir einen Grund zur Schließung mitteilen?


@Joe Doe - Ich meine 3 oder 4, exkl. zugesichertem,  aber nicht erfolgtem Rückruf und Wiederöffnung vorheriger Tickets.

Begründung wie hier im Thread ja beschrieben: Einmal Großstörung (die damit aber nichts zu tun hatte) , sonst WLAN bzw. ohne Begründung mit Link zur WLAN-Optimierungshinweisen.


und jetzt neu: 

Nur noch 8 Minuten!!!

 

Aber dafür habe ich eine Rückwegstörung 😂Geil!

 

Gruß

Dithmarscher1982


Alles OK bei mir, kann nicht genau sagen seit wann, gestern um ~08 Uhr warren noch ~18 min, jetzt 5 sec

 

Ich will noch beobachten.

Wie sieht es auch bei euch?

 

 


  ​@o2_Giulia Es gibt Neuigkeiten:

Dann war die Verbindung wohl für etwa 5 Stunden weg:

Und: 

So soll das aussehen!

Scheinbar wurde der Fehler behoben. Ich hoffe es jedenfalls.

Bei wem noch?

 

Gruß

Dithmarscher1982


Ich bekomme jetzt auch wieder wie früher innerhalb weniger Sekunden eine IP.

Dafür habe ich jetzt alle Nase lang für 20 Sekunden - 3 Minuten generelle Unterbrechungen ins gesamte Internet 😡
Dachte erst der DNS wäre die Ursache, ist es aber wohl nicht. Während dem Hänger lassen sich auch keine IPs von bekannten Inet Adressen pingen.

Sieht dann so und schlimmer aus:

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=458.006 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=45.562 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=21.029 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=56.274 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=22.965 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=868.093 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=959.565 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=59 time=19.593 ms
Request timeout for icmp_seq 8
64 bytes from 8.8.8.8: icmp_seq=9 ttl=59 time=291.650 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=59 time=47.422 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=59 time=21.407 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=59 time=21.339 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=59 time=29.877 ms
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
64 bytes from 8.8.8.8: icmp_seq=16 ttl=59 time=197.082 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=59 time=531.001 ms
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
64 bytes from 8.8.8.8: icmp_seq=19 ttl=59 time=2565.346 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=59 time=1717.684 ms
64 bytes from 8.8.8.8: icmp_seq=21 ttl=59 time=725.337 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=59 time=52.541 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=59 time=954.559 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=59 time=998.325 ms

 

Und - Nein - auch das ist kein WLAN Problem 😉


Vielleicht gehört das nicht mehr zu dem Thread, was sagt mtr? eventuell teste auf ipv6 auch


Vielleicht gehört das nicht mehr zu dem Thread, was sagt mtr? eventuell teste auf ipv6 auch

Kann schon sein, wollte es auch nur erwähnt haben - muss auch keiner drauf reagieren….


Deine Antwort