Kleines Update: ich würde alle Versuche mal einstellen. Bringt nichts. Es sind Ferien und ich kann mir vorstellen, dass man das Thema Anfang 2023 intern bei SC anschaut. Da IPv4 ja funktioniert, werden die 10 FRITZ!Box-Kunden auch weiterhin im Internet surfen können.

Alle Angaben wie immer ohne Gewähr und jeder wie er will.

wwe

ich habe einen weiteren Versuch unternommen und kurz “Rapid Commit” rausgenommen.. reconnect gemacht.. danach nochmal mit aktivem RC versucht.. beides erfolglos.. aber der Wireshark Trace zeigte einen spannenden Unterschied: der erste Solicit ohne RC hat einen Advertise vom DHCP Server bekommen (aber FB hat es nicht genutzt) und weitere Solicits sind nciht erfolgreich (vermutlich weil der DHCP Server denkt - “er hat schon alles, lass mich in Ruhe”).. ich denke ein AVM Support case loht sich.. sie können evtl sagen warum das Advertise nicht verarbeitet wird. interessant ist auch dass die FB immer wieder dieselbe XID benutzt..

wwe_0-1672087214187.png

@5018

Ich kann mir nicht vorstellen, dass IPv6 native nur mit einem Swisscom-Router gehen soll oder eine Aktivierung von einem Swisscom-Router benötigt.

Ich kann mir nicht vorstellen, wie du auf diese Aussage kommst, ohne jegliche Faktenlage.

  1. Schälterli.
  2. Authorisation.
  3. Fritten Konfiguration.
  4. (oder sonst eine Hypothese, die wir noch nicht entwickelt haben)

@5018

Kleines Update: ich würde alle Versuche mal einstellen. Bringt nichts. Es sind Ferien und ich kann mir vorstellen, dass man das Thema Anfang 2023 intern bei SC anschaut.

Magst du uns erzählen, wie du zu jetzt zu dieser Kehrtwende kommst?

@5018

Da IPv4 ja funktioniert, werden die 10 FRITZ!Box-Kunden auch weiterhin im Internet surfen können.

Ich hab mir heute Abend doch eine Zeitlang überlegt, was ich mit dieser Aussage anfangen soll. Richtig. V4 hat schon im Mai funktioniert, als ich diesen Thread gestartet habe. Darum geht es nicht. Ich möchte V6 zum Laufen bringen. Schon seit Mai 2022 und nicht erst im Anfang 2023. Aber scheinbar bin ich da etwas ungeduldig?

Ich weiss nicht, wie ihr Super-User so funktioniert. Ich bin da nur ein einfacher Ingenieur, der die Welt verbessern will. Es gehört zu meinem Beruf Fehler zu programmieren, sie zu finden und sie auch zu beheben. Und da bin ich nach wie vor an einer Win-Win-Situation interessiert. Zusammen mit meinen Kunden.

So und das Gegenargument wäre:

“Wäre schön was sachdienliches vom Betreiber zu hören, bin wohl kaum der Einzige mit einem Fremd-Router im Netz!? Ich mach dann auch einen schönen Know-how Artikel - so als Gegenleistung / Win-Win-Situation. ”

Den Deal kannst du vergessen, Swisscom liefert verständlicherweise keine Unterstützung für Fremdrouter.

Es liegt mir fremd, hier eure Weltanschaung zu verändern. Meine hat sich im Laufe dieser Diskussion / in diesem Thread sehr wohl verändert. Vielleicht habe ich nicht immer die richtigen Worte geschrieben. War tendentiös oder ungeduldig. Dennoch bin ich heute Abend einen Schritt weiter, weg von einer zementiertehn Haltung in Richtung von Wissen, Einsicht, Fortschritt. (Kopfschüttelnd ins Bett schluft.)

Ich hoffe, wir können uns morgen wieder den fachlichen Themen widmen.

Guetnacht Community.


@wwe schrieb:

aber der Wireshark Trace zeigte einen spannenden Unterschied: der erste Solicit ohne RC hat einen Advertise vom DHCP Server bekommen (aber FB hat es nicht genutzt) und weitere Solicits sind nciht erfolgreich (vermutlich weil der DHCP Server denkt - “er hat schon alles, lass mich in Ruhe”).

@wwe: Danke für die Info! 🤩Wenn du magst, kannst du mir den / die SOLICIT Anfragen in eine PN kopieren / schicken. Ich möchte die gerne anschauen und auf Unterschiede untersuchen. Oder aber gleich anonymisiert, wie ich es gemacht habe, hier kurz posten. Dann finden wir heraus:

  • Ob die Fritten aufgrund einer unterschiedlicher Konfiguration eine unterschiedliche DHCP Anfrage verschickt hat.
  • Oder aber ob sich das Backend unterschiedlich verhalten hat.

Ich denke wir kommen da Schritt für Schritt weiter in diesem Knobelspiel.

Guetnacht.

🙋‍♂️

@andiroid Wie ich zu meinen Aussagen komme? Der ist gut.

Klar könnt ihr weiter rumprobieren. Es wird nichts bringen. Das Thema ist bei der richtigen Person deponiert und nach den Weihnachtsferien wird man es anschauen. Und solange einfach mal die besinnliche Zeit geniessen und Katzenvideos anschauen, oder so.


@ChristianEb schrieb:

Scheint als müsste v6 übers Router GUI aktiviert werden zu müssen, ohne dies scheint auch für Fremdrouter dieser Service nicht zu funktionieren, so zumindest meine vermutung.

Ich denke, wir haben da noch überlagerte Probleme. Die F-Büxe von @wwe bekommt Antworten, aber etwas “verwirrte”. 🙂 Meine brüllt verzweifelt Pakete in den Äther und bekommt keine Antworten. Ich denke, dass wir das mit der Analyse der SOLICIT Pakete bestätigen können.

Denke somit zwei varianten, SCS “Router” an den Access hängen, Pairen, und option aktivieren, und anschliessend FB wieder anschliessen und pairen…

Ich werde diesen Work-around schon noch angehen. Ich krieg ja demnächst Glas (oder Plastik?). Und einen neuen Router.

Ich hätte noch eine notfall idee abet die wäre dann schon fast einwenig halsbrecherisch und brauchte eine weitere verbastelbare accessline…

Basteln!? Du bist über’s Warmlaufen hinweg gekommen und schon ganz ordentlich im Nerd-Mode angekommen. Genau nach meinem Gusto!

😁

Ernst: Was meinst du mit verbastelbarer Accessline? Ich meine, wenn es um einen temporären Versuch ohne grössere Kollateralschäden geht stelle ich mich zur Verfügung. Die Regentage laden ja förmlich zum Basteln ein. Wenn ich dann wieder in den Stollen muss, kann ich das aus Zeitgründen nicht mehr tun.

🫡


@wwe schrieb:

ich habe einen weiteren Versuch unternommen und kurz “Rapid Commit” rausgenommen.. reconnect gemacht.. danach nochmal mit aktivem RC versucht.. beides erfolglos.. aber der Wireshark Trace zeigte einen spannenden Unterschied: der erste Solicit ohne RC hat einen Advertise vom DHCP Server bekommen (aber FB hat es nicht genutzt) und weitere Solicits sind nciht erfolgreich (vermutlich weil der DHCP Server denkt - “er hat schon alles, lass mich in Ruhe”)

@wwe: Danke für die per PN zugesanten Logfiles.

1) Ich sehe keinen Unterschied in deinen und meinen Paketen. Ich denke, dass wir uns da einig geworden sind. Schälterli. Danke allen, die da ihren Beitrag dazu geleistet haben. Hüben wie drüben. 😉

2) Die Frage, weshalb die Fritte das ADVERTISE Paket verwirft, könnte mit der Regel 1 in der DHCPv6 Norm liegen. Das empfangene Paket enthält zwar einen ServerIdentifier, der Typ ist aber “Unknown”. Keine Ahnung, ob das jetzt schon Grund genug ist das Paket zu verwerfen.

Weiter bin ich in der Norm in [Kapitel 6](http://Operational%20Models) auf die Operational Models gestossen. Im Wesentlichen sind dies Stateless, Non-temporary und DHCP für Prefix Delegation.

  • Stateless hast du nicht angeboten bekommen. (Möglicher Grund?)
  • Non-temporary hast du angeboten bekommen. Leider aber mit Status-Code “NoAddrAvailable”. (Möglicher Grund?)
  • PD hast du erfolgreich angeboten bekommen. Sogar mit gültigem Prefix. Womöglich hat hier die Fritte den Prefix bekommen, gespeichert, aber weil kein weiterer Router im LAN sitzt auch nicht weiter gegeben.
    Auch hier mit Disclaimer: Ich bin da ganz und gar nicht der Spezialist. Aber wenn jemand da draussen mehr weiss, kann er mich da gerne aufklären. (@Tux0ne?)

3) Wir haben ausserdem noch keine Hypothese, mit welchem Verfahren dann trotzdem später eine IPv6 vergeben wird. Da fehlt uns ein eindeutiger Trace. Aber das könnte womöglich aus den Logfiles von “drüben” schneller zu einer belastbaren Antwort führen würden als mit riesigen Daten-dumps der Fritte. 😉

Ich denke, dass wir da zwar einen Schritt weiter sind und ein Fehler der Fritzbox nach wie vor nicht ausgeschlossen werden kann. Finde aber auch da im SOLICIT Paket (wie auch in der überflogenen Norm) keinen Hinweis, dass das RA-Verhalten beeinflussen könnte. Ich bin gespannt, was der @wwe da noch vom Feedback von Berlin berichten kann.

Hi @andiroid, danke noch das Du die AC Deines anschlusses mit mir geteilt hattest, wie in den Direktnachrichten erwähnt sehe ich zumindest in den letzen 15Tagen keine Radiusinformationen welche einen ipv6 delegated Prefix zeigen würden. was mich zu meiner vermutung brachte welche ich gestern geschrieben habe.
gerne würde ich fals möglich auch mal noch einen Blick in das von Euch gezogene Pcap werfen,

Gruss

Chris

Swisscom Network Engineer IP+ AS3303,


@ChristianEb schrieb:

Wie in den Direktnachrichten erwähnt sehe ich zumindest in den letzen 15Tagen keine Radiusinformationen welche einen ipv6 delegated Prefix zeigen würden. was mich zu meiner vermutung brachte welche ich gestern geschrieben habe.


Hey @ChristianEb, wärmster Dank für deine Bemühungen! 🎖️ Letztlich bestätigst du mir, dass wir von zwei überlagerten Problemen sprechen. Ich schätze deine proaktive Kommunikation sehr!

Ich gehe weiter davon aus, mit den IBs ein (proprietäres?) Protokoll verwendet wird, um damit v6 eingeschaltet werden kann. Wenn jemand von der RES CPE/Provisioning-Truppe da mehr weiss, würde ich da auch bei AVM einen Feature-Request stellen. (Das wäre dann aber eine punktuelle Lösung und andere Router hätten das selbe Problem…)

🤔

gerne würde ich fals möglich auch mal noch einen Blick in das von Euch gezogene Pcap werfen

Gibt es da schon erste Erkentnisse, oder bist du da (oder die Spezialisten-Truppe) noch am Knobeln?

😉

Ich habe jetzt auch ein Paketdump gemacht! Ein weiteres wunderbares Feature der F-Büxe! Können das die I-Büxen auch?

Nein, die IB kann das nicht und muss es auch nicht können.

Ich möchte ja nicht Öl is Feuer giessen oder mit euch herum trollen. Aber das Capture Feature der WAN Schnittstelle hat uns hier gezeigt, dass es manchmal unabdingbar ist auf zu verstehen, weshalb die Endgeräte sich unterschiedlich verhalten. (Der Vergleich von IB und FB hätte uns vielleicht auch etwas Zeit gespart?) Genau wegen diesen netten Featuers möchte ich meine Fritte lieber nicht her geben.

😇

hoi @andiroid, ich denke mit nichten das hier ein propriotäres protokol verwended wird. Ich nehme an das hier ein request an ein tool aus dem Gui gesendt wird welcher dann eine Toolchain dazu befähigt auf einer einzelnen accessline einen Service zu aktivieren oder in Deinem fall deaktiviert zu haben.

zu Deiner danksagung, gerne. Ich kann den need sehen das man gerne seine eigene HW an einem Access verwendet, dies bringt manchmal vorteile und ab und zu auch grosse Nachteile (wie jetzt in diesem hier…)

Gruss

Chris

Swisscom Network Engineer IP+ AS3303,


@ChristianEb schrieb:

hoi @andiroid, ich denke mit nichten das hier ein propriotäres protokol verwended wird. Ich nehme an das hier ein request an ein tool aus dem Gui gesendt wird welcher dann eine Toolchain dazu befähigt auf einer einzelnen accessline einen Service zu aktivieren oder in Deinem fall deaktiviert zu haben.

Hey @ChristianEb! Verstehe. 😉 Okay, wenn das dann ein REST API ist, welches mit standardisierten HTTP(S) Request hantiert, ist das Protokoll natürlich noch nicht proprietär. Da aber über die konkrete Implementation nichts bekannt ist, würde ich da schon bei proprietär bleiben. 😇

Ich dachte mehr an ein Verfahren zum Betätigen des Schälterlis, welches per RFC-wxyz Normiert worden ist und welches AVM nachbauen könnte. Glaube zwar nicht wirklich, dass ein solcher Vorschlag umgesetzt wird… 🙁

Fazit: Ich verstehe, das Problem. Im Falle eines Anschlusses mit deaktivierter IPv6 und ohne temporärer Zugriff auf eine IB gibt es aktuell keine Lösung. In meinem Fall nicht so schlimm, weil ich zeitnah Glas und dann vermutlich auch eine neue IB bekommen werde. Ich lass das mal so stehen.

Noch einmal herzlichen Danke @ChristianEb für die tolle Unterstützung!

🍾

  • wwe hat auf diesen Beitrag geantwortet.
  • Tux0ne gefällt das.

    andiroid

    hallo an alle konstruktiv beteiligte!

    wir haben mit Hilfe von @ChristianEb rausgefunden dass die FB eingestellt mit den Settings aus Post #57 ein DHCPv6 “Solicit” generiert, das DHCP Options 3 (IA_NA) und 25 (IA_PD) gleichzeitig enthält:

    wwe_0-1672267688011.png

    aktuell scheint die SCS Infrastruktur das nicht gut zu vertragen.. (an die Trolle: beide Optionen gleichzeitig zu senden ist RFC konform).. SCS möchte aber nur eine der beiden Optionen gleichzeitig..

    Ich habe Tests mit unterschiedlichen Fritzbox Einstellungen durchgeführt und rausgefunden dass FB mit folgenden Einstellungen ein DHCP Request mit Option 25 und ohne Option 3 erzeugen kann:

    wwe_1-1672268065757.png

    das widerspricht der Online-Hilfe von AVM und zeigte zuerst keinen Unterschied - kein IPv6 Prefix.. Ich habe allerdings aufgrund der Intervention des AVM Support meine FB 7583 von 7.29 auf 7.31 upgedatet.. und habe erstaunt festgestellt dass die FB direkt nach dem Reboot einen IPv6 Prefix bezogen hat!

    Das Update ist auf 7.31 ist schon länger verfügbar aber es wurde bei mir noch nicht automatisch gefunden..

    wwe_2-1672268442593.png

    Ich bin sicher dass ein Update auf 7.31 nicht notwendig ist vermute dass die Einstellungen auch mit 7.29 funktionieren. Ich wäre froh, wenn jemand mit FB 7.29 bestätigen kann dass Einstellungen

    - “use native IPv6”
    - derive global address using assigned prefix
    - rapid commit

    funktionieren und der IPv6 Prefix sofort nach Reboot/Reconnect bezogen wird.

    Gegen-Test mit 7.31 und den Einstellungen aus Post #57 resultierte in dem bekannten Fehler “Keine Antwort vom DHCPv6-Server (SOL)”.. das korrekte Verhalten konnte erst nach anwenden der o.g. Settings und DSL Trennung erreicht werden.

    Wichtiger Hinweis: wenn die FB “fehlerhafte” DHCP requests erstellt hat (und das macht sie jede Minute), werden neue Solicit Requests m.E. vom der SCS Backend für bestimmte Zeit blockiert/ignoriert.. und man muss nachdem korrekte Einstellungen konfiguriert sind, die Box für ca 90 Sec vom DSL trennen - danach funktioniert IPv6 sehr schnell sobald die DSL Verbindung aufgebaut oder “Reconnect” gedrückt wurde.. und statt wie bisher nach x Stunden..

    Im Februar sollte ein fix ausgerollt werden der dann Netzseitig mit beiden optionen gleichzeitig umgehen können sollte, somit sollte sich besagte Thematik bald bessern.

    Hat mit gefreut mit @wwe und @andiroid captures anschauen zu können. (Mal wieder eine etwas andere Freizeitbeschäftigung)

    Gruss

    Chris

    Swisscom Network Engineer IP+ AS3303,

    ein Monat später

    ich habe in der Zwischenzeit noch eine Info von AVM bekommen. mit der v7.50 - aktuell verfügbar für 7590 und in Zukunft für viele wichtige Fritten wie 7583 und sogar 7490 verfügbar sein wird - ändern sich IPv6 Profile. Ich weiss die Details leider nicht aber es besteht Hoffnung dass man in Zukunft “automatisch” nach der Swisscom Provider Auswahl die richtigen Einstellungen bekommt.. ich werde berichten sobald v7.50 für meine 7583 kommt..

    Habe aber in der Zwischenzeit absolut keine Probleme mit IPv6 gehabt.. gefühlt ist das Internet jetzt etwas mehr “responsive” - kann aber auch eine Einbildung sein vor Allem nach einigen Wochen unerklärlicher Phänomene nach IPv6 Ausfall und Tagen des “rumdoktorn” am Anschluss mit instabiler Konfig..

    13 Tage später

    kleines Update: habe diese Settings auch mit der 7583 v7.50 kurz getestet - IPv6 Verbindung funktioniert problemlos.

    ein Monat später

    hmm also bei meiner 7583 wird kein ipv6 hergestellt, nur ipv4.

    Software 7.5

    Hast du die Settings wie in Post #109 beschrieben konfiuriert und DSL für 10 Minuten getrennt?

    @wwe bist du verrückt? 10 Minuten DSL Trennen? Ich will doch keinen Ärger mit meiner Frau. 🤣

    Aber den Rest hab ich genau so eingestellt.😉

    OK habs jetzt doch gemacht. Mit selbem Ergebnis.

    Internetverbindung IPv6 konnte nicht aufgebaut werden: Keine Antwort vom DHCPv6-Server (SOL)

    ich würde dann vorschlagen einen network capture zu machen und anschauen was die FritzBox macht..