@ChristianEb

Aber am einzigen Uplink vom LAN zur IB abgegriffen gilt (abgesehen vom WEB-GUI-Traffic der IB) für die höheren Layer “LAN-Traffic = WAN-Traffic”. So gesehen braucht man den grossen Aufwand um das WAN zu monitoren nur für folgende Fälle:

- Es interessiert der Control-Traffic Swisscom <> IB

- Es interessieren die WAN-Pakete, welche an der Firewall der IB “abprallen”


@hed schrieb:

@ChristianEb

Aber am einzigen Uplink vom LAN zur IB abgegriffen gilt (abgesehen vom WEB-GUI-Traffic der IB) für die höheren Layer “LAN-Traffic = WAN-Traffic”. So gesehen braucht man den grossen Aufwand um das WAN zu monitoren nur für folgende Fälle:

- Es interessiert der Control-Traffic Swisscom <> IB

- Es interessieren die WAN-Pakete, welche an der Firewall der IB “abprallen”


@hed da bin ich nicht Deiner meinung, ich denke hier ist die abhängigkeit des usecases in betracht zu ziehen, für einen Debug wie ich es hier in beschriebenem problemcase machen würde braucht es nun mal schlicht und ergreifend keinen LAN traffic, da aus meiner sicht auf dem WAN Link der v6 part angesehen werden möchte, hierzu denke ich würde man sich erst mal nach dem WAN Link UP alle packete ansehen wollen, aus meiner sicht lässt nur das eine aussage zu auf welcher seite sich ein etweiliges Fehlverhalten zeigen würde.

Die IB wäre aus meiner sicht hier auch unintressant da hier anscheinend von einer Fritzbox gesprochen wird.

Bei einem cpe wie zb einem cisco hätte ich grundsätzlich sonst mal zu einem “debug ipv6…” geraten bevor ich den capture machen würde, jedoch scheint dies hier ja auch nicht der fall zu sein…

Weiterhin erholsamen abend

Gruss

Chris

Swisscom Network Engineer IP+ AS3303,
ASN3303

@ChristianEb: Danke, du wirst ja richtig warm mit uns! Nicht zynisch, sondern lobend gemeint! Was macht denn die Debug-Anweisung beim Cisco Router? Mehr V6 Traffic zur Analyse generieren oder aber mehr Debug Info für das Cisco Frontend erzeugen, so dass du auf die WAN Analyse u.U. verzichten kannst?

😉

Schööne Aabig öi allne!

🙋🏻‍♂️

Hahahahah @andiroid, ja hast recht, langsam, und warm…

Der debug output würde es erlauben dir anzuzeigen ob Du ein packet wie dass, welches umschrieben wird, dass nicht erhalten wird, auf dem cpe ankamm oder nicht…

Dies dann noch in einer verbose form, welches dann einwenig mehr sichtbar machen würde ob und wann….

Aber capturn ist auch gut…

Viel erfolg bei Euren tests

Chris

Swisscom Network Engineer IP+ AS3303,
ASN3303

@ChristianEb

Klar kommt es immer auf den Usecase an. Wenn z.B. eine IB/FritzBox o.ä. am WAN nicht hochkommt, ist nur der Trace am WAN interessant.

Für meine Usecases ist die IB die Demarkationsline zwischen Provider und Kunde und da überlasse ich die WAN-Seite dem Provider und mische mich nicht ein und messe demzufolge auch nicht am WAN-Interface.

Am besten wäre natürlich ein in der IB integrierter Sniffer mit dem man wahlweise am gewünschten Interface andocken könnte.

Liebe Community!

Ich hab jetzt einen Morgen lang den WAN Traffic von meiner Fritz!Box abgegriffen und angeschaut. Nebenbei noch einmal mit meinen V6 Settings noch hin und her probiert, versucht herauszufinden welches Setting welchen Unterschied verursacht und versucht zu verstehen wie DHCPv6 in (rfc8415) funktioniert. Womit ich nicht behaupte, dass ich jetzt jede Option verstanden habe. Ich hatte durchaus den Eindruck, dass der Ablauf durchaus richtig war. Der Unterschied Nativ V4 und Nativ V6 ist definitiv die Reihenfolge, ob zuerst V4 oder V6 ausgehandelt wird.

Mein Verfahren ist folgendes:

  1. IPv6 Einstellungen geprüft / verändert.
  2. Die Support Seiten der Fritzbox geöffnet (Unten Links: Inhalt, dann Mitte Unten: Fritz!Box Support)
  3. Paket Sniffing für den WAN Port eingeschaltet.
  4. Den Knopf [DSL-Verbindung neu synchronisieren] gedrückt.
  5. Ein paar Minuten gewartet.
  6. Paket Sniffing für den WAN Port ausgeschaltet. Das generiert ein Wireshark kompatibles.ETH File.
  7. Das File mit Wireshark Portable geöffnet und gefiltert.

Der Verbindungsaufbau sieht folgendermassen aus:

andiroid_1-1672048546760.png

Es passieren noch ein paar andere DHCPv6 Anfragen. Zuerst in 2.5s Abständen, später in grösseren Intervallen (1.5min). Der Wechsel zu den längeren Intervallen passiert, nachdem im System/Ereignisse die Fehlende Antwort vom DHCPv6 Server protokolliert wird:

andiroid_0-1672050869428.png

Die Theorie würde hier eigentlich ein RA (ADVERTISE) Paket erwarten.

Der Vollständigekeit halber bekommt ihr hier noch das anonymisierte DHCPv6 Paket:

Frame 12194: 185 bytes on wire (1480 bits), 185 bytes captured (1480 bits)
Ethernet II, Src: AVMAudio_23:a4:f8 (aa:bb:cc:dd:ee:ff), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Internet Protocol Version 6, Src: fe80::wwww:xxxx:yyyy:zzzz, Dst: ff02::1:2
User Datagram Protocol, Src Port: 546, Dst Port: 547
DHCPv6
    Message type: Solicit (1)
    Transaction ID: 0x114267
    Elapsed time
        Option: Elapsed time (8)
        Length: 2
        Elapsed time: 1070ms
    Client Identifier
        Option: Client Identifier (1)
        Length: 10
        DUID: 000300015c497923a4f8
        DUID Type: link-layer address (3)
        Hardware type: Ethernet (1)
        Link-layer address: aa:bb:cc:dd:ee:ff
    Rapid Commit
        Option: Rapid Commit (14)
        Length: 0
    Identity Association for Non-temporary Address
        Option: Identity Association for Non-temporary Address (3)
        Length: 12
        IAID: 7923a4f8
        T1: 0
        T2: 0
    Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 41
        IAID: 7923a4f8
        T1: 0
        T2: 0
        IA Prefix
            Option: IA Prefix (26)
            Length: 25
            Preferred lifetime: 0
            Valid lifetime: 0
            Prefix length: 0
            Prefix address:::
    Reconfigure Accept
        Option: Reconfigure Accept (20)
        Length: 0
    Option Request
        Option: Option Request (6)
        Length: 18
        Requested Option code: DNS recursive name server (23)
        Requested Option code: NTP Server (56)
        Requested Option code: Simple Network Time Protocol Server (31)
        Requested Option code: Identity Association for Prefix Delegation (25)
        Requested Option code: Identity Association for Non-temporary Address (3)
        Requested Option code: Vendor-specific Information (17)
        Requested Option code: SOL_MAX_RT (82)
        Requested Option code: INF_MAX_RT (83)
        Requested Option code: PCP Server (86)
    Vendor Class
        Option: Vendor Class (16)
        Length: 4
        Enterprise ID: AVM GmbH (872)

Ich kann mir nach wie vor keinen Reim machen, weshalb ich kein Router Advertisement bekomme. Mitlerweile hab ich dafür 3 Hypothesen:

  1. Es gibt trozdem ein “Schälterli” für V6 ein/aus, welches an meinem Anschluss auf aus ist. (Ok, ok, ich möchte hier nicht selber auch noch mittrollen, ich hab gehört und gelesen, dass es dies nicht gibt! 😉)
  2. Eine Variation davon wäre, wenn mein Anschluss nicht vollständig Authorisiert worden ist. (https://www.swisscom.ch/access) Aufgemacht, durchgespielt, keine Probleme. (Klar, kriege ja auch eine V4 Adresse, weshalb soll ich das nicht dürfen?) Wäre aber ein möglicher Grund, weshalb die RAs bewusst / absichtlich nicht geschickt würden. Sonst könnte ja an jedem Anschluss V6 aktiviert / benützt werden. Auch, wenn der Kunde kein Internet bezahlt.
  3. Meine Fritte hat nach wie vor einen üblen Konfigurations-Fehler. Glaube ich aber nicht mehr. So viele Möglichkeiten gibt nämlich nicht.
    Wenn ihr den im SOLICIT Paket-Mitschnitt findet: Finde den einen Unterschied.

Ich komme da alleine nicht weiter und bin auf eure Hilfe angewiesen. Vielleicht kann jemand mal diesen Mitschnitt für die I-Büxe machen. Mich interessiert insbesondere:

  • Das zeitliche Verhalten. (Wie schnell kommen das ADVERTISE auf das SOLICIT Paket?)
  • Die inhaltlichen Unterschiede des SOLICIT Paketes. (Mit denen könnte ich wieder bei AVM anklopfen.)

Ich hoffe ich kann den einen oder anderen Nerd motivieren. Ihr müsst aber Zugang zum WAN Traffic haben. Entweder über einen Medien-Konverter oder aber mit der oben beschriebenen Magie. Es könnte auch ein Fritzbox Mitschnitt sein von einem Anschluss, der schon einmal mit IPv6 funktioniert hat.

Challenge Accepted!?

🙋‍♂️

  • wwe hat auf diesen Beitrag geantwortet.

    Hi @andiroid zwei fragen, gehe ich richtig in der annahme das Du hier im capture die soucre deiner Box gecaptured hast? (Da ja source AVM)

    Somit vermute ich das die log message was erwartet was nicht kommt, ich würde mich auf das fokusieren was du von seite netzt erhälst und wie Deine box dies verwerten muss.

    Deine box kenne ich leider gar nicht, hatte vor gefühlten 20Jahren mal ne fritzbox, jedoch denke ich kenne ich da nichts mehr aktuelles…

    Meine vermutung ist nachwievor eine falsche option auf seite deiner box

    Gruss und viel spass beim basteln

    Swisscom Network Engineer IP+ AS3303,
    ASN3303


      ChristianEb schrieb:

      Hi @andiroid zwei fragen, gehe ich richtig in der annahme das Du hier im capture die soucre deiner Box gecaptured hast? (Da ja source AVM)

      Danke, @ChristianEb für’s Mitdenken und Anspornen. Du findest tatsächlich keine Info auf welchem Port du welche Infos kriegst. Da muss Mann etwas interpretieren. Es gibt drei Schläuche, welche ich abhören kann:

      andiroid_0-1672053367176.png

      Der Traffic von “1. Internetverbindung” und “Schnittstelle 0” ist identisch. Der DHCPv4 Verkehr ist ja auch sichtbar und dürfte keinesfalls an den LAN Ports auftauchen.

      Die “Routing-Schnittstelle” ist übrigens der reine IP Verkehr, den habe ich noch nicht angeschaut.


      @ChristianEb schrieb:

      Somit vermute ich das die log message was erwartet was nicht kommt, ich würde mich auf das fokusieren was du von seite netzt erhälst und wie Deine box dies verwerten muss.

      Gruss und viel spass beim basteln


      Korrekt vermutet, die Log-Message ist ja auch stimmig. Mein Fokus ist genau dort, wo du ihn auch festzurrst. Ich krieg vom Netz keine einziges V6 Paket. Null. Nada. Nur “meine” SOLICIT Anfragen. Deshalb meine wirren Hypothesen bezüglich “Schälterli” “Aktivierung” “Proprietäre TR-069 Kommunikation”. Ich will da wirklich keine Stimmung machen, verstehe aber das Schweigen der Router an dieser Stelle tatsächlich nicht…

      😟

      Wenn du www.swisscom.ch/access besuchst, kommt da die blaue Start Seite mit Swisscom Logo wo du dich mit Seriennummer oder Swisscom Logo registrieren kannst? Spiele das nochmals durch. Kommt eine weisse Seite wo man die NSN Nummer die man vom Provider bekommt, wären wir schon bei der legacy IP auf dem falschen Dampfer.

        @andiroid Du hast mich hier falsch verstanden, ich spreche nicht vom port (lan, wan, etc…) Ich sehe das es angezeigt das die src des captures avm war, aus meiner sicht müsste dies der huawei bng sein, dieser spricht doch zu Dir.

        Bitte lass mich nich per dm deine ac Nummer wissen, danke

        Gruss

        Chris

        Swisscom Network Engineer IP+ AS3303,
        ASN3303

        • andiroid hat auf diesen Beitrag geantwortet.

          Tux0ne schrieb:

          Wenn du www.swisscom.ch/access besuchst, kommt da die blaue Start Seite mit Swisscom Logo wo du dich mit Seriennummer oder Swisscom Logo registrieren kannst? Spiele das nochmals durch.

          Danke auch dir fürs Mitdenken. Hab ich eben das 2. Mal gemacht. Hier kommt relativ schnell:

          andiroid_0-1672061022998.png

          Alles sehr schräg. 😉


          ChristianEb schrieb:

          @andiroid Du hast mich hier falsch verstanden, ich spreche nicht vom port (lan, wan, etc…) Ich sehe das es angezeigt das die src des captures avm war, aus meiner sicht müsste dies der huawei bng sein, dieser spricht doch zu Dir.

          Bitte lass mich nich per dm deine ac Nummer wissen, danke

          Jäso, nicht der Port. 😉 SRC/DST ist alles Definitionssache - immerhin die ip.src und ip.dst aus den Logfiles haben den “richtigen” Bezugspfeil:

          andiroid_0-1672063659580.png

          Da sehe ich noch keinen groben Schnitzer…

          andiroid

          Um einen Vergleich zu haben wollte ich schauen wie es mit DHCPv6 bei mir aussieht nachdem ich einen IPv6 Prefix hatte - nach einem “Reconnect” bekomme ich wieder keine IPv6, sehe die bekannte Fehlermeldung.. bin jetzt gespannt ob die IPv6 wieder irgendwann in der Nacht wieder von allein kommt..

          Interessant ist, dass ich in meinem Wireshark DCHPv6 Solicit requests der FB sehe und für die ersten Paar Requests auch DHCPv6 Reply von fe80::200:5eff:fe00:116 bekomme mit einem Fehler - Status code 13 (UnspecFail).

          wwe_0-1672064967093.png

          rfc8415:

          | UnspecFail | 1 | Failure, reason unspecified; this status |
          | | | code is sent by either a client or a |
          | | | server to indicate a failure not |
          | | | explicitly specified in this document.

          Dabei “versteht” der DHCP server die FB grundsätzlich - die unmittelbar vorangegangene DHCPv6 Release wurde akzeptiert.. Evtl hat es ein Problm damit dass der Solicit zu schnell reinkommt - lt Trace sogar früher als die Release Ack eintrifft..

          wwe_0-1672066391825.png

          Hat jemand einen erfolgreichen DHCPv6 Wireshark Trace verfügbar? Ist es ein Timing Thema? falsche/fehlende DHCP Options?

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

            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.

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

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

            Gruss

            Chris

            Swisscom Network Engineer IP+ AS3303,
            ASN3303

            @ChristianEb

            Die Frage stellt sich, welcher Befehl von der IB in Richtung Provider gesendet wird, wenn das IPv6-Häckchen in der GUI ausgewählt wird.

            Hallo @hed, diese Auskunft habe ich so selbst auch nicht, ich bin hier leider “nur” ein Netzi, und nicht in RES CPE/Provisioning involviert.

            Gruss

            Chris

            Swisscom Network Engineer IP+ AS3303,
            ASN3303

            Ich kann mir nicht vorstellen, dass IPv6 native nur mit einem Swisscom-Router gehen soll oder eine Aktivierung von einem Swisscom-Router benötigt. Das würde jeder Architektur widersprechen, die jemals diskutiert wurde. Es gibt doch auch ein paar Kunden, die sich einen Zyxel-Router gekauft hatten, da dieser vor dem Release der IB4, die einzige Möglichkeit war, die 10 GBit/s E2E auf ein Gerät zu bringen. Wenn es da geht, da gibt es vielleicht einen Bug in der FB oder was auch immer.

            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.