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
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:
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:
Da sehe ich noch keinen groben Schnitzer…
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).
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..
Hat jemand einen erfolgreichen DHCPv6 Wireshark Trace verfügbar? Ist es ein Timing Thema? falsche/fehlende DHCP Options?
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
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.
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.
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..
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.
- Schälterli.
- Authorisation.
- Fritten Konfiguration.
- (oder sonst eine Hypothese, die wir noch nicht entwickelt haben)
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?
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,
ASN3303
@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,
ASN3303
@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!
