Stand domain split Essen

Ich verstehe nicht was du meinst. Der wird doch benutzt. Es geht darum, welche Firmware dem Autoupdater ausgehändigt wird, wir geben ja jetzt nicht mehr statisch die selbe Firmware an alle Router, die beim selben Server nach der selben Datei fragen, sondern je nach Domäne unterschiedliche. Und wenn wir einfach jedem Node das Update geben zerfällt das Wifi-Mesh und die dahinterliegenden Nodes sind offline und nie wieder erreichbar ohne manuellen Eingriff am Gerät.

Wie sieht es denn mit der Subdomäne RG-West aus?

Genau… und da die Essener Router wegen einer Fehlkonfiguration mit den Ruhrgebietsroutern meshen (BSSID ist gleich), brauchen wir das doch garnicht, wenn wir über die Essener Supernodes Zugriff auf die Updateserver geben, die die Ruhrgebietsrouter anfragen.
D.h. mit ein paar IP-Rules können wir ALLE Ruhrgebietsknoten in Essen auf die Essener Firmware updaten und niemand wird ausgeschlossen. Im zweiten Update müssen wir dann die BSSID ändern und das funktioniert wahrscheinlich problemlos mit dem Gluon Autoupdater.
Wir brauchen in Essen dein Script mit den erweiterten Funktionen für Knoten, die keinen Uplink haben wahrscheinlich garnicht.
Womöglich kannst du die jetzt einfach alle updaten und wenn nicht, müssen wir ein paar Routen auf den Essener Supernodes setzen…

EDIT: Wenn du Lust hast, kann ich ja mal nen Router ohne Uplink mit der Ruhrgebietsfirmware flashen und den mit einem Essener Router mit Uplink meshen lassen. Dann versuchst du den zu updaten und wir sehen, obs funktioniert…

Übrigens hätte ich es sinnvoll gefunden, wenn das Ruhrgebiet vor dem Umzug auf eine Firmware mit einem verkleinertem Updateintervall geupdatet worden wäre, damit man verlorengegangene Knoten mit einem mobilem Knoten und gefaktem Updateserver hätte updaten können.
Hast du denn ein Backup von den JSON-Files, damit wir überhaupt feststellen können, wo ein Knoten verloren gegangen ist?

Wieso sollten sie? Die Knoten haben doch genug Zeit, um sich die Updates runterzuladen. Das was du jetzt machst, ist nicht besser als der Autoupdater.
Mit Probability wird gesetzt, wann die ersten Knoten anfangen, die Updates zu installieren.Mit Priority wird gesetzt, wann die Knoten auf jeden Fall ihr Update installieren.

Priority=3, Probability=0.6 heißt soweit ich weiß:
Nach 3 Tagen müssen alle Knoten geupdatet sein. Nach nicht ganz zwei Tagen fangen die ersten an, die Updates zu installieren. Und sobald die Router ein neues Update entdecken, laden sie es sich in den RAM (am Tag 0 sozusagen)…

Router werden nur ausgeschlossen, wenn irgendein Depp seinen Router ohne Uplink immer ausschaltet (denn dann geht der RAM-Inhalt verloren) und das Zufällig in dem Fall zwischen Tag 2 und 3…

Weisste, wenn du das alles so viel besser weißt, warum machst du’s nicht oder hast es schon längst gemacht?

Wir habe hier 14 Domänen und nicht nur Essen, da interessiert mich der Fuckup mit der BSSID in Essen nur am Rande.

Ich würds ja machen, aber ich hab keinen Zugriff auf die Server…

Mich hingegen interessiert der Fuckup, weil wir hier nen Haufen Cross-Community-Traffic haben und dein derzeitiges Vorgehen das Problem nicht löst, sondern die Server nur noch mehr belastet.

die router bleiben ja in dem JSON drinne. Die werden nicht gelöscht, sondern nur nach 2 tagen nicht mehr als „verschwunden“ angezeigt

Ich habe bei mir nen Meshviewer installiert, der sich die nodes.json per Runwhen runterlädt. Da waren heute mittag nur noch etwa 110 Knoten drin.
Gut, dann lade ich mir mal ein Backup, falls da wieder auf myteriöse Weise Knoten verschwinden…

Kaum spreche ich drüber, sind die Knoten schon wieder verschwunden…
Werde mal in den Logs nachsehen. Vielleicht ist das ein Problem mit meinem Server…

ich meinte die JSON an sich … da sollten keine Nodes verschwinden … ich hab da noch 30 Tage alte Testnodes drin, die seitdem nicht mehr online waren

ABER, wenn du die von dem RG Server ziehst, dann ist das richtig, da die nicht von dem backend, sondern von dem Splitter erzeugt werden … die original JSON hat aber alle Nodes inne (EDIT: ich glaube, das ist so. Das müsste ich nochmal nachschauen. Also, das der Splitter die offline Nodes auslässt)

Also ich lade immer die http://map.freifunk-ruhrgebiet.de/data/nodes.json runter und filtere die Nodes für Essen raus.
Jetzt gerade sind wieder alle Knoten drauf und die Datei hat etwa 3,4MB. Davor, als dieser Screenshot entstanden ist, hatte die Datei nur 1,9MB und es war beides valides JSON. Sehe ich alles im Runwhen-Log. Wenns kein valides JSON gewesen wäre, hätte mein Script nicht die JSON-Datei von der Karte aktualisiert…

Was macht ihr mit der nodes.json, dass der mir die valide rausspuckt, aber mit fehlenden Knoten?

EDIT: Also wenn ein Backup existiert, ist ja alles in Ordnung, aber dass heute spontan Knoten nicht angezeigt werden, habe ich natürlich mit dem Update in Verbindung gebracht. Hat ja aber wohl nichts damit zu tun… Denn sonst passiert das nicht…

Das ist eine gute Frage. Bei den ganzen Projekten aktuell kann ich dir das aber nicht zuverlässig aus dem Kopf beantworten. Ich werde das aber morgen nachschauen und dir dann Feedback geben.

Gruß

Chrisno

Moin, ich hab das gerade mal nachgeschaut. Die offline Nodes werden auch übernommen.

Gruß

Chrisno

Das Problem sind
a) temporäre Routing-Probleme. Gerade in völlig überlasteten Domains in Verbindung mit schwachen Links kann es sein, dass ein Node die Updates nur mit vielen, vielen Retries komplett geholt bekommt vor dem Stall.
b) In überlasteten Domains neigen 4MB-RAM-Geräte dank des tollen™ DHCP-Scripts dazu, ggf. im 2h-Abstand kalt zu booten wegen Kernelpanik/Ramüberlauf/Watchdog etc.

Sprich: Gerade in solchen Szenarien ist es wahrscheinlich, Nodes beim Update zu verlieren.

Am Wochenende habe ich mich durch den Autoupdater-Sourcecode durchgewurstelt und er kann überhaupt nicht das, was ich erwartet habe.

Die Probability bestimmt einfach nur mit Zufallszahlen, ob der Knoten updatet, damit nicht alle Knoten gleichzeitig updaten. Die Wahrscheinlichkeitsfunktion die dafür genutzt wird, sieht ein bisschen wie eine halbe Sinuswelle aus.
Die Knoten laden sich das Update nur unmittelbar davor runter.
Ich habe mir vorgenommen, in den nächsten Tagen eine Funktion für Gluon zu bauen, damit der Knoten, wenn er keinen Uplink hat und nicht meshen kann, versucht sich über das Clientnetz eines benachbarten Freifunkknotens das Update zu besorgen. Dann kann man zukünftig auch problemlos den Kanal oder die BSSID ändern, so lange das Clientnetz die gleiche SSID hat.

ranlvor hatte das wohl schon mal vorgeschlagen und ihm wurde gesagt, er solle es scripten und es wird eingebaut.

Schöne Grüße,
Vincent

2 „Gefällt mir“