Mehre Knoten in Rorup sind Offline und es befinden sich Router mit der Firmware für Dülmen in der Domain? z.B. FFMS-Rorup-33
@prototyp
@descilla ist bereits per Threema alamiert worden und hat das Script gestoppt.
In der Dom12 sind Knoten aus Lüdinghausen, Rorup, Havixbeck, etc. gelandet. Und Knoten die in der Dom12 sind werden teilweise noch auf der Karte in Dom02 angezeigt, obwohl Sie die Software der Dom12 haben.
@descilla wird sich asap darum kümmern. Geht aber gerade nicht. … Diese nicht vorhandenen SLAs! 
2 „Gefällt mir“
Alsbald mich @dippydipp anschrieb, habe ich den Migrationsprozess gestoppt.
Es scheint eine Brücke entstanden zu sein, vermutlich durch mesh on lan. Dadurch haben einige Knoten aus der Domäne 2, auch aus Bereichen außerhalb von Dülmen eine 2a03:2260:115:1200:: bzw. 2a03:2260:115:1300::
Da jedoch im Firmware-Server jedoch die Adressen aus den Domänen 12 und 13 eben zur entsprechenden Domäne weitergeleitet haben, haben sich Knoten die FW gezogen, die es eigentlich nicht sollten.
Ursache gefunden, Problem beseitigt, das ist schon mal gut. (FW von dom 12 und 13 steht jetzt explizit nur den eingetragenen Knoten zu, nicht allen Knoten mit einer Adresse aus dom 12 und 13, zumindest solange das Update noch läuft).
Jetzt geht es ans aufräumen. Die Knoten, die in der Karte 12 und 13 aufgetaucht sind, sind unproblematisch, die schiebe ich einfach wieder zurück. Problematischer sind eher die Knoten, die keinen direkten VPN Zugang haben. Diese muss ich erst ausfindig machen und dann den vorgeschalteten VPN-Knoten umziehen, um dann den den Mesh Knoten rück-umzuziehen, um dann den VPN-Knoten rück-umzuziehen.
Ich hoffe mal, dass wir das ohne Außeneinsatz hinbekommen, kann aber wohl den Abend, bzw. die halbe Nacht dauern.
PS: Nicht unbedingt alle Knoten, die in den neuen Karten aufgetaucht sind, haben sich die falsche Firmware gezogen. Durch die Brücke können sie auch einfach nur vom Alfred erkannt worden sein. Ich kann es aber derzeit nicht genauer testen, weil es in der FH nur IPv4 gibt. Ich bin gleich zuhause, dann schaue ich mir das genauer an.
@MPW, @Alucardo : muss ich etwas beachten, wenn ich l2tp Knoten nach fastd zurück-umziehe?
Man kann Knoten nicht zurück nach fastd ziehen. Dafür bräuchte man ein extra Migrationspaket und das haben wir nicht drin.
Zumindet müsste man das nochmal testen.
Welche Firmware ein Knoten wirklich hat, kannst du auf der Karte unter dem Punkt „site“ sehen.
Es scheinen 7 Knoten betroffen zu sein (einer davon in Rorup, der ja definitiv automatisch umgezogen werden kann).
Die Brücke ist im Übrigen durch diesen Knoten entstanden: https://karte.freifunk-muensterland.org/map_Kreis_Coesfeld/#!v:m;n:c4e984e35550
Dieser wird jetzt isoliert umgezogen, danach schaue ich weiter.
Hat jemand einen SSH-Zugang auf einen Knoten in Domäne und kann dort mal folgendes ausführen und die Ausgabe hier posten?
ping6 firmware.ffms
Ich nicht. Vieleicht @Gunnar.
@descilla einen Knoten in Domäne 12 oder 13? Oder Domäne 02? In letzterer könnte ich das tun.
Welche Knoten aus LH sind denn betroffen? Muss ich aktiv werden?
@descilla Genau wie @scroom sagt. Zugriff auf welchen Knoten?
Muss ich am Knoten SPD 002 in Dülmen noch was machen?
Wenn ich das richtig sehe, sind folgende Knoten in LH betroffen (sie werden in der Karte von Dom 12 angezeigt):
http://[2a03:2260:115:1200:32b5:c2ff:fee2:f5de]/
http://[2a03:2260:115:1200:16cc:20ff:fe97:f84a]/
http://[2a03:2260:115:200:32b5:c2ff:feee:1fc0]/
http://[2a03:2260:115:200:6a72:51ff:fe2e:e379]/
http://[2a03:2260:115:1200:32b5:c2ff:fec8:8b3a]/
http://[2a03:2260:115:200:c66e:1fff:fe7a:99da]/
Wobei folgende Knoten auf der Karte von Dom 12 als offline angezeigt werden und als online in Dom 02:
http://[2a03:2260:115:200:c66e:1fff:fe7a:99da]/
http://[2a03:2260:115:200:32b5:c2ff:feee:1fc0]/
Sind diese schon zurückmigriert?
Außerdem wollte ich noch anmerken, dass so etwas immer mal passieren kann! Ihr macht eine tolle Arbeit!
1 „Gefällt mir“
https://karte.freifunk-muensterland.org/map12/#!v:m;n:30b5c2c88b3a
https://karte.freifunk-muensterland.org/map12/#!v:m;n:14cc2097f84a
https://karte.freifunk-muensterland.org/map12/#!v:m;n:30b5c2e2f5de
Sind in Lüdinghausen betroffen.
Knoten, die in der Karte von Domäne 12 als offline angezeigt werden, sind _nicht_betroffen.
Grund: Durch den „Kurzschluss“ durch zwei MoL Knoten sahen die Netze 02 und 12 für Batman/auf layer2 wie ein großes Netz aus. Daher wurden halt auch Knoten aus Domäne 02 in die Karte von Domäne 12 gezeichnet. Leider haben dadurch auch einige Knoten mit der „falschen“ IPv6 Adresse (nämlich die mit dem Prefix aus Dom12) beim Firmwareserver nachgefragt und sich daher fälschlicherweise die falsche Firmware gezogen.
Seit dem der Kurzschluss beseitigt ist, werden die Knoten, die sich nicht die falsche Firmware gezogen haben in der Karte der Domäne 12 als offline angezeigt (diese sollten aber in der Karte von Dom 02 als online angezeigt werden).
Knoten, die jetzt noch auf der Karte von Dom 12 online sind und nicht in Dülmen stehen, haben wohl die Falsche Firmware bekommen.
Tipp: Wenn du auf der Karte von Domäne 12 auf „Statistiken“ klickst und bei „Firmwareversionen“ auf „v2016.1.3+1.0.9“ klickst, werden alle nicht betroffenen Knoten ausgeblendet.
Hinweis: Da alle Knoten gleichermaßen auf die falsche Firmware zugreifen konnten, werden sich vermutlich auch Mesh-on-WLAN Knoten die Firmware gezogen haben. Diese erscheinen natürlich nicht in der Karte (wenn der zugehörige VPN-Knoten nicht ebenfalls die Firmware gezogen hat). Durch das Verhältnis an Mesh-only Knoten kann man erahnen, wie viele hier betroffen sind.
Leider ist das nginx-logfile durch den Kurzschluss nur bedingt brauchbar. Ich muss hier noch explizit auf die korrekte Dateigröße beim Download prüfen, bevor ich Aussagen darüber treffen kann, welche Knoten betroffen sind (/sein könnten).
Nein, nachdem ich dem gestern noch mal in den Hintern getreten habe, ist er korrekt umgezogen.
@MPW hat gestern noch mal versucht eine Rück-Migrationsfirmware zu bauen, aber ich weiß nicht wie hoch er dort die Erfolgsaussichten sieht. Die drei Knoten in Lüdinghausen funktionieren ja erstmal. Ich persönlich würde daher erstmal abwarten.
Nachdem ich gestern die Brücke geschlossen hatte, hat kein Knoten mehr aus Domäne 02 beim Firmwareserver angefragt (zuvor haben alle mit einem Prefix aus Domäne 12 mit dem FW Server gesprochen). Dadurch ist natürlich die Knotenmigration ins Stocken geraten. Ich wollte Ursachenforschung betreiben und brauchte dazu einen „befallenen“ Knoten (Knoten, der zur Zeit des Kurzschlusses in Domäne 02 war). Also einen beliebigen. Mittlerweile haben die Knoten aber das „falsche“ Prefix aufgegeben. Im Nachgang ist hier interessant herauszufinden, warum das so lange gedauert hat.
…ich halte euch auf dem Laufenden…
Ne, ich hab einfach nur getestet, was wirklich passiert. Nachdem mir aber das Autoupdate von 02 auf 12 die VM zweimal komplett gebraten hat, hatte ich keine Lust mehr. Müsste man mal auf einem 841er oder so testen.
Dom02 ohne Übernahme der Konfiguration → fastd aktivieren → sysupgrade auf Dom12 → sysupgrade auf Dom02 zurück. Und dann ist zu prüfen, ob der Knoten dann offline ist.
3 „Gefällt mir“
Hi,
es gab gerade eine Netzwerkbrücke per LAN zischen DOM02 und DOM13. Diese wurde eingerissen.
Ein Futro war noch in DOM02 und hat per Kable eine Pico in DOM13 versorgt, die auch schon per Funk Mesh mit einem anderen Uplink in DOM12 versorgt war… Habe den Futro manuell per Smartphone schnell umgezogen.
Gruß
Nicklas
1 „Gefällt mir“
Danke. Wollte gerade schreiben, dass das dieses mal nur meine Arbeit erschwert aber nicht dazu führt, dass weitere Knoten die falsche Firmware bekommen.
PS: Es gibt eine weitere Brücke, die durch Rorup-31/Rorup-32 geht.
1 „Gefällt mir“
Kein Remotezugriff - wird gerade abgeschaltet und bekommt die Firmware manuell.
1 „Gefällt mir“
@descilla @MPW Wenn ihr kein Skript zum remigrieren habt, dann fahre ich da die Tage vielleicht besser vorbei, da jetzt einige Mesh-Knoten so offline sind. Oder plant ihr in den nächsten Tagen auch die Domäne02 umzustellen, so dass sich die Arbeit nicht lohnen würde?
Es müsste einfach mal jemand testen.
Das kann iwie jeder tun. Ich hab es virtuell probiert, das ist fehlgeschlagen, weil sich die VM immer weggehängt hat, das hatte aber nichts mit Domänenwechsel zu tun. Bitte einfach mal auf einem 841er testen, dann wissen wir es.
Ich würde erst morgen dazu kommen. Freiwillige vor…
Laut @Jannis soll das funktionieren. Er hatte das vorhin mal getestet.
@scroom Gibt es einen Knoten (der “befallenen” in Lüdinghausen), an dem ich das mal “in freier Wildbahn” testen darf? (komme aber frühestens morgen dazu)