Beiträge von ::1

Zitat von JaFr

Anbei der gewünschte Paketmitschnitt mit dem Dauerping.

Zitat von ::1

Ich schaue mir die letzten Paketmitschnitte heute abend nochmal an und ergänze/modifiziere ggf. noch die Fehlerdiagnose um weitere Erkenntnisse.

Die aktuellen Mitschnitte bringen keine wirklich neuen Erkenntnisse, bestätigen aber das bisherige Bild. Man kann noch herauslesen, dass sich die MAC-Adresse der DG-Gegenstelle (20:00:00:00:32:26) offenbar für etwa 40 Sekunden (siehe 13.) im Neighbor Cache für den WAN-Port der FB befindet:

1. Pakete 1404-1475:
   
   Die von der FB an die SNMA ff02::1:ff00:22 der DG-Gegenstelle (abgeleitet aus deren IPv6-Adresse fe80::22) gesendeten NS (Neighbor Solicitations) bleiben von der DG-Gegenstelle unbeantwortet (Fehler seitens DG). Die FB sendet die NS per Multicast an die SNMA der DG-Gegenstelle, weil sie zu diesen Zeitpunkten deren MAC-Adresse 20:00:00:00:32:26 nicht (mehr) kennt, da sie sich nicht mehr im Neighbor Cache für den WAN-Port der FB befindet.
   
2. Pakete 1490-1500:
   
   Von dir ausgelöster Reconnect der FB: Die FB autokonfiguriert sich ihre linklokale IPv6-Adresse fe80::e72:74ff:fec7:97e6 und führt für diese eine DAD (duplicate address detection) durch: Pakete 1490-1491. Anschließend sendet sie RS (Pakete 1492-1495) und MLD-Reports (Pakete 1499-1500). Soweit alles normal/korrekt.
   
3. Paket 1504:
   
   Bravo: Die DG-Gegenstelle sendet ein RA (wenigstens das - immerhin) als Antwort auf die von der FB gesendeten RS:
   
   Dies hat zwei Aspekte zur Folge:
   Die FB lernt daraus die IPv6-Adresse der DG-Gegenstelle als Standardgateway (fe80::22).
   Eine im RA enthaltene Option teilt der FB auch die zugehörige MAC-Adresse der DG-Gegenstelle (20:00:00:00:32:26) mit.
   Diese speichert die FB in ihrem Neighbor Cache (dort wird sie allerdings irgendwann gelöscht, wenn sie zwischendurch nicht von der DG-Gegenstelle bestätigt wird, z.B. weil die FB nicht aktiv per NS nachfragt, nachdem eine Weile kein ausgehender IPv6-Unicast Traffic mehr auftritt).
   
4. Paket 1840:
   
   Die FB hat jetzt alle Informationen, um das erste PINGv6-Paket zu senden: Sie verpackt das ausgehenden IPv6-Paket in einen Ethernet-Frame mit der Ethernet-Zieladresse 20:00:00:00:32:26 der DG-Gegenstelle, die sie aus ihrem Neighbor Cache auslesen kann.
   
5. Paket 2459-2460:
   
   Da die FB die MAC-Adresse der DG-Gegenstelle nur "als Beifang" aus dem RA erhalten hat, muss sie diese durch eine NS/NA-Transaktion verifizieren. Sie sendet die NS per Unicast an die IPv6-Adresse fe80::22 der DG-Gegenstelle (verpackt in einen Ethernet-Frame mit der Zieladresse 20:00:00:00:32:26 der DG-Gegenstelle). Die DG-Gegenstelle antwortet mit NA - ebenfalls per Unicast. Soweit normal.
   
6. Pakete 4312-33307:
   
   Die FB sendet weitere PINGv6-Pakete im Zeitabstand von 5 Sekunden. Alle PINGv6-Paket bleiben unbeantwortet. Die DG-Infrastruktur scheint entweder die ausgehenden PINGs nicht korrekt zum Ziel (hier: Facebook) oder aber die PING-Antworten vom Ping-Ziel nicht korrekt zurück zur FB zu routen (Fehler seitens DG).
   
7. Pakete 33308-41163:
   
   Weitere ausgehende Pings, die unbeantwortet bleiben - eingestreut immer wieder NS/NA-Transaktionen (vgl. 5) zur Bestätigung der MAC-Adresse der DG-Gegenstelle. Jede NA-Antwort setzt den Timeout für die Verweildauer des Neighbor Cache-Eintrags (fe80::22 -> 20:00:00:00:32:26) wieder auf ihren Maximalwert (müssten etwa 40 Sekunden sein, s.u.)
   
8. Pakete 41346-41347:
   
   NS/NA mal umgekehrt! Die DG-Gegenstelle fe80::22 möchte die zur globalen IPv6-Adresse deiner FB (2a00:6020:9480::86) gehörende MAC-Adresse deiner FB (0c:72:74:c7:97:e6) bestätigt bekommen. Einkommende NS per Unicast (Paket 41346) wird von der FB ordnungsgemäß mit einem NA per Unicast zurück an fe80::22 beantwortet (Paket 41347).
   
9. Pakete 41360-42528:
   
   wie 7.
   
10. Pakete 42529-42530:
    
    Letzte NS/NA-Transaktion, die von der DG-Gegenstelle beantwortet wird! Der Timeout für die Verweildauer der MAC-Adresse der DG-Gegenstelle im Neighbor Cache wird zum Zeitpunkt ~210s nochmal auf ihren Maximalwert gesetzt.
    
11. Pakete 42559-44549:
    
    Weitere ausgehende, aber unbeantwortete Pings.
    
12. Pakete 44550-44690:
    
    Interessant: Die FB sendet erneut mehrmals NS für fe80::22 zur Bestätigung der MAC-Adresse der Gegenstelle. Nun werden diese aber nicht von der der DG-Gegenstelle beantwortet (Fehler seitens DG)!
    
13. Pakete 44700ff:
    
    Zum Zeitpunkt ~250s (Paket 44700) scheint der Cache-Timeout (der sich aus der Differenz 250s - 210s (siehe 10.) zu ~40s ergibt) abgelaufen zu sein: Die MAC-Adresse 20:00:00:00:32:26 der DG-Gegenstelle befindet sich ab nun nicht mehr im Neighbor Cache. Die FB muss sie also durch Senden von NS an die SNMA ff02::1:ff00:22 der DG-Gegenstelle neu ermitteln. Aber wie schon in 1. festgestellt, beantwortet die DG-Gegenstelle NS, die an ihre SNMA gesendet werden, nicht.
    
    Da die FB nun nicht mehr über die Ziel-MAC-Adresse der DG-Gegenstelle verfügt, kann sie auch keine ausgehenden Pings mehr senden, da sie diese nicht mehr in Ethernet-Frames verpacken kann (es kann keine Ethernet-Zieladresse eingetragen werden). Deshalb sieht man im Mitschnitt auch keine ausgehenden Pings mehr.
    
    Der Mitschnitt endet im Nirwana mit nur noch ausgehenden NS an die SNMA der DG-Gegenstelle, die von dieser aber nicht beantwortet werden.
    

Fazit:

Zusammenfassend lassen sich folgende Fehler festhalten, für die allein DG verantwortlich ist:

• Es gelingt zwar, dem Router IPv6-Adressen zuzuweisen - diese wechseln jedoch mit jedem Reconnect. An DG-Privatanschlüssen sind die IPv6-Adressen quasistatisch (aber nicht garantiert), ein Wechsel der Adressen bei jedem Reconnect deutet erfahrungsgemäß auf einen seitens DG nicht funktionierenden IPv6-Zugang hin. Auffällig sind hier immer wieder jene IPv6-Ranges (hier 2a00:6020:9480::/41 mit WAN-Adressen in 2a00:6020:9480::/112), in denen DG aktuell ein neues Adressierungsschema einführt.
• Die DG-Gegenstelle (hier fe80:22) beantwortet generell keine NS, die per Multicast an ihre SNMA (solicited node multicast address, hier: ff02::1:ff00:22) gesendet werden. NS, die sie per Unicast (an fe80::22) erhält, werden offenbar nach einer bestimmten Zeit ebenfalls nicht mehr beantwortet. Dies führt dazu, dass dem Kundenrouter die MAC-Adresse der DG-Gegenstelle abhanden kommt, und er in der Folge keine IPv6-Unicast-Pakete mehr ausgehend Richtung Internet senden kann.
• Da erfolgreich an die DG übermittelte PINGv6-Pakete (ICMPv6 Echo Request) zu allgemein pingbaren Internet-Zielen (z.B. facebook.com = 2a03:2880:f176:181:face:b00c:0:25de) nicht per ICMPv6 Echo Reply beantwortet werden, ist anzunehmen, dass die IPv6-Adressen des Kundenanschlusses innerhalb der DG-Netzinfrastruktur nicht korrekt geroutet werden (vermutlich nicht funkionierende IPv6-Rückwärts-Routen zum Kundenanschluss).

Ich schaue mir die letzten Paketmitschnitte heute abend nochmal an und ergänze/modifiziere ggf. noch die Fehlerdiagnose um weitere Erkenntnisse.

Das Verhalten der DG im Umgang mit solchen Fehlern ist ein anderes Thema, da kann sich jeder seinen Teil denken.
Du kannst allenfalls eine Frist zur Behebung setzen mit Androhung der Halbierung des Monatsbetrags (für das halbe Internet, das du bekommst) bis hin zur Kündigungsdrohung. Falls du aber keine Alternativen zur DG-Glasfaser hast, hast du die A....karte - DG weiß das sicherlich ganz genau.

Zitat von JaFr

Gibt es denn anhand der bislang verfügbaren Mitschnitte eine Idee, weswegen es mit IPv6 nicht funktionieren will?

Eine Zwischenbilanz:

1. DG scheint den IPv6-Range (/56-PD-Block für das LAN, WAN-Adresse), den es deiner FB zuweist, nicht zu routen. Beleg dafür sind die IPv6-Pings, die deine FB von deinem LAN-PC über den WAN-Link zu DG routet, die aber sämtlich nicht beantwortet werden (Mitschnitt: no response found!).
2. DG weist dir keine festen IPv6-Adressen für WAN und LAN zu - diese ändern sich mit jedem Reconnect. Normalerweise sind die zugewiesenen IPv6-Adressen auch an Privatanschlüssen konstant (wenn auch nicht garantiert, erfahrungsgemäß aber über sehr lange Zeiträume). In allen, hier im Forum zu findenden Fällen mit gleichem Verhalten an DG-Anschlüssen gab es stets IPv6-Probleme. Insofern kann man im Umkehrschluss annehmen, dass mit jedem Reconnect wechselnde IPv6-Adressen mit hoher Wahrscheinlichkeit auf ein seitens DG nicht funktionierendes IPv6 hinweisen.
3. Der letzte Paketmitschnitt zeigt, dass von deiner FB gesendete NS (Neighbor Solicitations) an die Unicast-Adresse (fe80::22) der DG-Gegenstelle von dieser mit NA (Neigbor Advertisment) beantwortet werden. NS/NA via Unicast sind aber lediglich Bestätigungen dafür, dass die im Neigbor Cache der FB befindliche MAC-Adresse der DG-Gegenstelle (20:00:00:00:32:26) noch aktuell ist, denn andernfalls würden die NS per Unicast (also in Ethernet mit der MAC-Zieladresse 20:00:00:00:32:26 enkapsuliert) die DG-Gegenstelle gar nicht erreichen.
   
   Wird die MAC-Adresse im Neighbor Cache der FB nach kurzer Zeit der Inaktivität gelöscht, so kann sie anschließend durch Senden von NS an die aus der IPv6-Adressen fe80::22 abgeleitete SNMA ff02::1:ff00:22 der DG-Gegenstelle nicht mehr aufgelöst werden, weil die Gegenstelle diese NS nicht per NA beantwortet (vorletzter Paketmitschnitt). In der Folge kann kein IPv6-Paket mehr ausgehend über den WAN-Link zu DG gesendet werden.
4. Die dir zugewiesenen IPv6-Adressen liegen in einem der IPv6-Ranges, in denen DG ein gegenüber älteren Anschlüssen geändertes IPv6-Adressvergabe-Schema einführt (hier: /56-LAN-Präfix aus 2a00:6020:9480::/41, WAN-Adresse in 2a00:6020:9480::/112). Es wurden in diesem Forum schon viele IPv6-Problemfälle diskutiert, die ebenfalls in IPv6-Ranges mit "neuem" IPv6-Adressvergabe-Schema liegen. DG-seitig scheint da noch vieles "im Argen" zu liegen.

Ja, das Speichern der Datei auf dem LAN-Rechner bricht ab, wenn die Verbindung zwischen Windows-PC und FB über IPv6 erfolgt. Mit Auslösen von "Neu verbinden" zieht man sich quasi die IPv6-Verbindung selbst weg (Absägen des Astes, auf dem man sitzt). Mit IPv4 kann das nicht passieren, da die RFC1918-Adressen bei einem Reconnect ja erhalten bleiben.

Aber dein letztes Wireshark-Bild zeigt nun ja das gewünschte Ergebnis ...

Bzw. mach doch nochmal das, was ich eben schrieb (Dauerping und 5 Minuten laufen lassen) - will sehen, ob so nach etwa 2 Minuten keine ausgehenden Ping-Versuche mehr im Mitschnitt zu sehen sind.

Ich schreibe nachher noch was zur Analyse ...

Ruf die Paketmitschnitt-Seite deiner Fritzbox bitte mal über ihre IPv4-Adresse auf:

http://192.168.178.1/html/capture.html (Adresse ggf. anpassen)

Dann sollte es mit dem Speichern der Capture-Datei unfallfrei klappen.

Mich würde die Sichtbarkeit der ausgehenden Pings im Mitschnitt in den ersten 2 Minuten nach einem Reconnect schon interessieren.

Ich denke, die Reihenfolge sollte wie folgt sein:

1. Starte an einem LAN-PC eine Eingabeaufforderung und setzte dort einen Dauerping auf Google ab: ping -6 -t google.com. . Starte optionial pro weiterem Ziel (z.B. facebook.com) jeweils eine weitere Eingabeaufforderung, um dort einen analogen Dauerping abzusetzen.
2. Starte den Paketmitschnitt http://192.168.178.1/html/capture.html (Adresse ggf. anpassen)
3. Führe in der Fritzbox (zweite Anmeldung in einem separaten Browser-Fenster: http://192.168.178.1 ) einen Reconnect ("Neu verbinden") durch.
4. Lass den Paketmitschnitt etwa 5 Minuten laufen.

Zeige das Wireshark-Ergebnis mit dem Ansichtsfilter icmpv6

Okay, der Mitschnitt zeigt leider nicht, wie erhofft, die ausgehenden Pings (das wären ICMPv6-Pakete des Typs 128 (echo), Wireshark-Filter icmpv6.type==128). Das liegt vermutlich daran, dass deine FB diese Pings nicht Richtung DG senden kann, weil ihr dazu die MAC-Adresse der DG-Gegenstelle fehlt - die braucht sie als Ethernet-Zieladresse für die ausgehenden Ping-Pakete. Stattdessen sieht man nur, wie deine FB ständig NS (Neighbor Solicitation) an die Gegenstelle sendet (genauer: an die aus deren Adresse fe80::22 abgeleitete SNMA-Adresse ff02::1:ff00:22), um eben genau diese fehlende MAC-Adresse der Gegenstelle aufzulösen. Leider antwortet die Gegenstelle nicht mit einem NA (Neighbor Advertisement).

Nach einer Neuverbindung deiner FB mit dem Internet hat sie diese MAC-Adresse aus den erhaltenen RA noch für etwa 2 Minuten in einem Cache. Wenn du innerhalb dieser Zeitspanne nach einer Neuverbindung diese Pingtests durchführst, dürftest du in einem Paketmitschitt diese ausgehenden Pings (als ICMPv6-Pakete des Typs 128) noch sehen - müsstest nur schnell genug sein. Beantwortet würden sie allerdings vermutlich nicht, so dass die Pings auch hier fehlschlagen würden.

Zitat von maik6849

Weil es eine einzelne Adresse ist.

ja klar, aber wenn sie per SLAAC aus den RA der FB gebildet wurde, müsste sie einen /64 aufweisen.

zu "mngtmpaddr" siehe hier. Werde allerdings auch nicht recht schlau daraus ...

Auffällig noch:

inet6 2a00:6020:x000:xx00:0000:x000:x00x:4977/128 scope global dynamic

Wieso /128 und nicht /64?

Zitat von Xonic207

Ja, das scheint so der Fall zu sein, zwar ist es ein Feld in dem man auch selbst "reinschreiben" kann, aber dann kommt die Meldung: "Keine Übereinstimmungen".

Die Bereitstellung eines ordentlichen Manuals für das "UGOS Pro"-OS des NAS scheint der Hersteller wohl nicht für nötig zu halten (fragt auch der User "Merkur" im Ugreen-Forum)?

Zitat von pufferueberlauf

??? Wenn das NAS sich die IPv6 per DHCPv6 zuweisen laesst, warum kann dann nicht der Router eine solche zuweisen?

Vergleiche hier: Da habe ich so eine dynamische Konfiguration unter [1.] beschrieben.

Es wurde alles schon mal diskutiert - nur nicht in diesem Thread ...

Zitat von Xonic207

bzw. den Post von ::1 anschauen.

das wäre kein Hexenwerk.

Vergleiche hier: Da habe ich so eine statische Konfiguration (für ein QNAP-NAS) beispielhaft unter [2.] beschrieben.

Siehe auch diesen Thread zum Thema.

Zitat von HubeBube

Nichts, außer dem schon erwähnten und die Vergesslichkeit, falls sich doch der Präfix irgendwann ändern sollte.

Ja, aber ich sehe auch keinen besseren Vorschlag, außer es ganz sein zu lassen - bzw. es weiterhin via VPN zu betreiben (was im übrigen auch deutlich sicherer ist).

Was spricht gegen meinen Workaround-Vorschlag in #20?

Zitat von maik6849

Das Problem ist das NAS was keine dauerhafte IPv6 nimmt

So ist es, die Hersteller des NAS-OS haben da bzgl. "Privacy über alles" versus feste IPv6-Interface-ID für Server leider die falschen Prioritäten gewählt.

Workaround: Das NAS statisch konfigurieren und dafür eine Freigabe einrichten. Das muss man dann nur in den seltenen Fällen anpassen, wenn einem DG ein neues IPv6 LAN-Präfix verpasst.

Ich verweise auf meinen ersten Beitrag: Du könntest in der FB den IPv6 Interface Identifier einfach mit dem Identifier der temporären GUA überschreiben und die Freigabe dann für diesen Wert durchführen - dann würde der Zugriff von außen vermutlich funktionieren. Aber du hast damit keine Dauerlösung, falls das nur ein temporärer Identifier ist, der sich z.B. nach einem NAS-Neustart ändert.

Zitat von Xonic207

Auch wenn ich auf „Exposed Host“ umschalte komme ich von Außen nicht drauf.

Ich weiß nicht, wie du "von außen" testest: Falls mit Smartphone, musst du auf dem natürlich "WLAN" ausschalten, und dein mobile Provider muss deinem Phone auch eine IPv6-Adresse spendieren.

Und wie gesagt, IPv6-Adresse des NAS in der Zielansprache in eckige Klammern setzen (später wirst du die sicherlich über DynDNS auflösen wollen):

https://[2a00:6020: ... :f3ed]:9999

Nicht wundern, wenn du hierfür einen Zertifikatsfehler kassieren wirst.

Formal sieht das gut aus!

Allerdings scheinst du mit jedem Reconnect neue IPv6-Adressen zu bekommen - nach bisherigen Erfahrungen ist das kein gutes Zeichen!

Mach bitte mal Folgendes:

• Starte einen Paketmitschnitt am WAN-Port deiner FB
• Führe an einem deiner PC im LAN folgende PING-Tests aus:
  - ping -6 google.com
  - ping -6 facebook.com
  - ping -6 wikipedia.org
• Stoppe den Paketmitschnitt und poste hier dessen Ergebnis mit dem Ansichtsfilter "icmpv6"

Ich erwarte, dass im Mitschnitt nur ausgehende Pings zu sehen sind, jedoch keine Antworten.

Na, pingen kannst du das NAS von außen natürlich nicht, weil du dafür keine ICMPv6-Freigabe eingerichtet hast (zumindest sehe ich das nicht).

Du kannst laut FB-Freigabe nur einen HTTP-Connect via 9999\tcp testen:

http://[IPv6-Adresse des NAS laut GUA - (2a00:6020: ... :f3ed)]:9999

(IPv6-Adresse muss mit [ ] umgeben werden!)

Nachtrag:

Ich gehe davon aus, dass du die FB-Freigabe für das NAS anhand dessen "IPv6-Interface-ID" und somit passen für die "IPv6-GUA" (und somit nur für diese) eingerichtet hast. Für diese "IPv6-Interface-ID" muss ferner gelten: Sie muss wirklich fest sein, darf sich nach einem Neustart des NAS oder nach der Zuweisung eines neuen IPv6-LAN-Präfix durch DG nicht ändern! Wenn diese "IPv6-Interface-ID" in der Mitte z.B. das Muster "ff:fe" aufweist, und "f3ed" auch am Ende der NAS-MAC-Adresse auftaucht, kannst du davon ausgehen, dass sie tatsächlich konstant ist.

• Ok, ICMPv6 in den RA hast du aufgeklappt -> der Inhalt ist aus meiner Sicht ok.
• Leider hast du es nicht geschafft die DHCPv6-Informationen aufzuklappen (die Protokolle davor kannst du zugeklappt lassen), so dass ich da jetzt leider nicht schlauer werden kann. ...

Aber schau mal in deiner FB unter Heimnetz | Netzwerk | Netzwerkeinstellungen | Button "IPv6-Einstellungen": Dort ganz unten: Was wird da unter "Verwendete IPv6 Präfixe:" angezeigt? Bitte Screenshot posten: