Intermittierende Verbindungsstörungen, kein Abbruch (FB 6591, VF/UM)

[frfrfr]

Hallo,
ich habe die Frage schon im VF-Forum gestellt, aber ich hoffe mal, dass hier etwas mehr "Expertise" unterwegs ist

Folgendes vorab: ich möchte die Hardware ausschließen, da das Problem bereits vor Monaten mit der UM Connectbox sowie der VF Station, die dann als Ersatz geliefert wurde, aufgetreten ist. Ich habe mich dann für die FB 6591 entschieden und dachte, der Spuk wäre vorbei. Isser aber nicht.

Problembild: Meine Verbindung bricht absolut random mehrmals täglich/wöchentlich ab; allerdings bleibe ich weiter "online". Seitenaufbau in Chrome ist nicht mehr möglich, aber diverse Apps halten die Verbindung trotzdem, bspw. Spotify oder auch einige Online-Games.
Das Problem tritt sowohl bei LAN-Geräten (PC, SmartTV, PS4) sowie WiFi-Geräten (Laptop, Smartphone, Alexa) auf.

Ich habe dann mal versucht, mit Wireshark irgendwas zu ermitteln, habe aber im Grunde null Plan, was da passiert. Ich konnte den Fehler soweit eingrenzen, dass Wireshark mir folgende Zeile anzeigt, wenn die Verbindung mal wieder abbricht - siehe Screenshot

Die erste IP (81.xxx) ist anscheinend ein VF-Server, die andere mein PC. Wenn ich mir die Details anschaue sehe ich, dass unterschiedliche IPs nicht erreicht werden können. Trotzdem ist ein Ping oder tracert möglich, manchmal mit, manchmal ohne Timeout.

Ich habe wirklich keine Ahnung mehr, was ich als Laie da noch machen kann. Ich kann gerne mehr Logs oder Screenshots posten, falls das hilfreich wäre; für den Moment wäre mir schon sehr geholfen, wenn mir jemand sagen kann, ob das an VF, meiner Leitung, dem DS-lite-Tunnel oder was weiß ich liegt.

 

[cvzone]

Kannst du mal nen Screenshot der Kanalübersicht der 6591 posten? (Modulations- und Dämpfungswerte)

 

[frfrfr]

Klar, gerne. Vorab dazu: Techniker war bereits einmal vor Ort und hat im Keller etwas gedreht, die Messungen waren aber wohl im Rahmen, auch Vergleichswerte, die ich so gefunden habe, scheinen i.O. zu sein.

Letzter Restart war übrigens gestern abend gegen 23:30 Uhr.

 

[Mojo1987]

Das klingt doch ganz klassisch nach Problemen mit dem DNS und wäre auch nicht das erste Mal. Wenn Spiele und Spotify weiterlaufen aber keine Seite mehr aufgerufen werden kann ist das fast immer ein Auflösungsproblem. Hast du testweise mal lokal am Rechner die DNS Server hart auf die von Google z. B. gestellt?

 

[frfrfr]

Ok, da kommen wir zu dem Punkt, wo ich nicht mehr sicher bin. Die Fritzbox - obwohl meine eigene - lässt keine Konfiguration des DNS zu; wo/wie müsste ich da in Windows vorgehen?
Und müsste das dann entsprechend bei allen anderen Geräten ebenfalls gemacht werden? PS4, SmartTV, Alexa, Tablet und was hier noch so alles rumliegt?

Gibt es evtl. eine Möglichkeit, in Wireshark einzusehen, ob es ein spezifischer Seitenaufruf ist, der den Fehler "triggert"? Ich könnte halt nicht sicher sagen, welches "Event" oder welche Anfrage den Fehler verursacht; am ehesten auffallen tut es eben am PC, aber betrifft dann wie gesagt alle Geräte.

 

[cvzone]

An den DNS hatte ich auch gerade gedacht. Die Leitungswerte sind trotz der minimalen korrigierbaren Fehler top. Die Moduliation ist ja auf allen Kanälen auf QAM256, das sieht man selten.

Ergänzung (8. April 2020)

Konfiguration des DNS zu; wo/wie müsste ich da in Windows vorgehen?

Du kannst den Geräten über die DHCP Einstellungen in der Fritzbox einen neuen DNS zuweisen lassen, dann musst du das nicht überall per Hand einstellen.

Fritzbox: Heimnetz->Netzwerk->Netzwerkeinstellunge->IP4 Adressen.

 

[Atkatla]

Wieso wird hier immer gleich die Konfiguration eines anderen DNS empfohlen, anstatt das vorher erstmal zu testen, ob das überhaupt das Problem ist? Sonst weiss man doch gar nicht, ob man nun wirklich das Problem adressiert.

@frfrfr :

• Den DNS auf normal (also den des Providers) lassen.
• wenn alles normal funktioniert, eine DNS-Abfrage (bei Windows z.B. per nslookup) machen

-- dazu cmd (Kommandozeile aufrufen)
-- nslookup www.computerbase.de eingeben, es wird dir nun angezeigt, welche IP-Adresse dein Resolver von wem bekommen hat

- wenn das Problem wieder auftritt, das Gleiche tun und das Ergebnis vergleichen, konnte die Abfrage ausgeführt werden, wurde eine Antwort geliefert oder gab es einen Time-Out?

Dann kann man sehen, ob wirklich der DNS-Server des Providers keine Antwort geliefert hat, oder ob etwas deinen Resolver im System durcheinander bringt.
Wenn man der Meinung ist, dass ein DNS-Server des Providers keine oder eine falsche Antwort liefert, kann man nslookup anweisen, einen Server direkt zu befragen:

• nur "nslookup" auf der Kommandozeile eingeben
• "server 8.8.8.8" sorgt dafür, dass alle folgenen nslookup-Anfragen an 8.8.8.8 gesendet werden (bis das Tool beendet wird)
• wieder ein paar Testanfragen schicken

Auf diese Weise kann man DNS-Anfragen gezielt an bestimmte DNS-Server-IPs schicken und so feststellen, ob einer nicht korrekt funktioniert oder ob die Kette vorher irgendwo unterbrochen wird.

 

[frfrfr]

Ok, aktuell funktioniert alles, entsprechend bringt mir der nslookup folgendes Ergebnis, wird wohl richtig sein so:

@Atkatla
Habe ich das richtig verstanden: Wenn der Fehler das nächste mal auftritt mache ich zunächst den "einfachen" Lookup wie im Screenshot und schaue, was passiert.
Anschließend das ganze nochmal, nachdem ich den Lookup-Server auf "8.8.8.8" geändert habe, und vergleiche die Ergebnisse, um zu sehen, ob der DNS-Server das Problem ist?

@cvzone
In der Fritzbox also hier:

den Wert zu o.g. 8.8.8.8 ändern? Oder eben irgendein anderer DNS-Server, der "stabile Ergebnisse" bringt?

 

[cvzone]

@Atkatla Ja, ist alles richtig, setzt nur ein gewisses Netzwerkwissen und die Auswertung dieser Informationen voraus. DNS ändern und gucken ob das Problem weg ist ist auch ein "Testverfahren".

Aber frfrfr hat aber wohl Ahnung, daher ist dein Vorschlag schon gut.

 

[Jasmin83]

Die Moduliation ist ja auf allen Kanälen auf QAM256, das sieht man selten.

ach echt? ich hab jetzt und mit der vorherigen 6430 cable auch 256QAM auf allen 24x5 Kanälen (VF/UM BW)

 

[cvzone]

ach echt?

Liegt auch ein bisschen im Netzbereich wo man sich befindet. Ich bekommen hier in Hannover so gut wie immer auch den Bereich ab 780 Mhz zugeordnet und die laufen ganz oft nur mit QAM64.

 

[Jasmin83]

ah, ich seh gerade, meine höchste frequenz ist 770MHz. Bin gespannt wann es hier mit DOCSIS 3.1 weitergeht..

 

[Atkatla]

@Atkatla
Habe ich das richtig verstanden: Wenn der Fehler das nächste mal auftritt mache ich zunächst den "einfachen" Lookup wie im Screenshot und schaue, was passiert.
Anschließend das ganze nochmal, nachdem ich den Lookup-Server auf "8.8.8.8" geändert habe, und vergleiche die Ergebnisse, um zu sehen, ob der DNS-Server das Problem ist?

Genau.

 

[frfrfr]

Alles klar, dann warte ich mal ab, was meine Verbindung heute den Tag über so macht. Ich melde mich, sobald es was Neues gibt, wie gesagt, das kann in einer halben Stunde sein oder auch erst morgen.

Danke schonmal für den ganzen Input bis hierhin, wäre natürlich super, wenn es "nur" an dem DNS-Server läge, ich hoffe einfach mal, dass ich nicht anfangen muss, hier komplette Wireshark-Logs posten zu müssen.

An dieser Stelle noch die Frage, weshalb ein Neustart der Fritzbox den Fehler behebt?! An den Einstellungen ändert sich ja nichts...?

 

[Atkatla]

Wenn der Resolver in der Fritzbox sich aufhängt oder nicht mehr sauber arbeitet (der leitet ja die Anfragen deiner Clients an die externen DNS-Server weiter), wird das durch einen Reboot behoben.

 

[bender_]

Die Leitungswerte sind trotz der minimalen korrigierbaren Fehler top.

Würde ich so nicht sagen. Der DOCSIS 3.1 Kanal ist für 4kQAM grenzwertig untersteuert. Eigentlich seltsam, da alle anderen Kanäle ganz gute Pegelwerte aufweisen. Da der 3.1 Kanal in höherem Frequenzbereich als alle anderen liegen, könnte eine veraltete Komponente im Strang die Ursache sein.
Es kann sein, dass dadurch ständig zwischen Modulationsstufen umgeschaltet wird, was solche Ausfälle bedingen kann.
Ich würde Vodafone darauf hinweisen und einen Techniker anfordern.

 

[frfrfr]

Danke für den Hinweis, Vodafone will mir die Tage nochmal wen vorbeischicken, alle Infos, die ich da weiterleiten kann sind herzliche willkommen.
Sind das denn dann Probleme, die mit einem Entstörfilter (keine Ahnung, irgendwo aufgeschnappt) erledigt sind, oder müssen die dafür das Haus, die Straße und die A1 nebenan kernsanieren?

 

[frfrfr]

So, kurzes Update: Fehler trat gerade wieder auf, der nslookup hat allerdings das selbe korrekte Ergebnis wie zuvor gebracht, auch ohne den Server zu 8.8.8.8 zu ändern.
Ich habe dann testweise mal in der Fritzbox den DNS zu 8.8.8.8 geändert, machte aber auch keinen Unterschied.

Die "administratively filtered communication" wird auch immer nur von einem UM/VF-Server ausgegeben, wobei dahinter immer eine andere "Destination-IP" (siehe Log) steht.

Wenn ich den Eintrag im Detail öffne erhalte ich dieses hier (tut mir leid, jetzt kommen doch die Logs, ich bin langsam mehr genervt als verzweifelt):

Frame 27859: 94 bytes on wire (752 bits), 94 bytes captured (752 bits) on interface \Device\NPF_{EFEBC6BE-8585-4397-BC59-28AC605BD3A7}, id 0
Ethernet II, Src: fritz.box (dc:39:6f:be:fa:97), Dst: MeinPC.local (e0:d5:5e:d3:e2:41)
Internet Protocol Version 4, Src: de-krp01b-rd01-ae0.krp.unity-media.net (81.210.141.2), Dst: MeinPC.local (meine.ip)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 80
Identification: 0x848b (33931)
Flags: 0x4000, Don't fragment
Fragment offset: 0
Time to live: 63
Protocol: ICMP (1)
Header checksum: 0x658e [validation disabled]
[Header checksum status: Unverified]
Source: de-krp01b-rd01-ae0.krp.unity-media.net (81.210.141.2)
Destination: MeinPC.local (meine.ip)


Internet Control Message Protocol
Frame 27859: 94 bytes on wire (752 bits), 94 bytes captured (752 bits) on interface \Device\NPF_{EFEBC6BE-8585-4397-BC59-28AC605BD3A7}, id 0
Ethernet II, Src: fritz.box (dc:39:6f:be:fa:97), Dst: MeinPC.local (e0:d5:5e:d3:e2:41)
Internet Protocol Version 4, Src: de-krp01b-rd01-ae0.krp.unity-media.net (81.210.141.2), Dst: MeinPC.local (meine.ip)
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 13 (Communication administratively filtered)
Checksum: 0xc2cf [correct]
[Checksum Status: Good]
Unused: 00000000
Internet Protocol Version 4, Src: MeinPC.local (meine.ip), Dst: aacfb9d106f4.link11.de (128.65.210.181)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 52
Identification: 0xcc03 (52227)
Flags: 0x4000, Don't fragment
Fragment offset: 0
Time to live: 126
Protocol: TCP (6)
Header checksum: 0x6b0a [validation disabled]
[Header checksum status: Unverified]
Source: MeinPC.local (meine.ip)
Destination: aacfb9d106f4.link11.de (128.65.210.181)
Transmission Control Protocol, Src Port: 49155 (49155), Dst Port: https (443), Seq: 3457491950



Ist jetzt irgendwer irgendwie schlauer?


EDIT: Gerade wieder. Auch, wenn das hier evtl. gar nichts bringt nochmal 2 Screenshots. Interessanterweise wird die erste Anfrage "gefiltered", ist aber per ping/lookup erreichbar, im zweiten Fall scheint die Domain nicht mal zu existieren. Keine Ahnung, ob das irgendwas zu sagen hat. DNS-Server ist nach wie vor der Fritzbox-Standard. Die zweite - nicht-existente IP - habe ich dann auch nochmal mit 8.8.8.8 als DNS-Server getestet, da gibt es eine Zeitüberschreitung.

Und damit euch nicht langweilig wird hier noch ein IPv6-Test während des Fehlers sowie nach einem Neustart der Fritzbox: