Bei solchen Knoten hilft es dann aber auch nicht, wenn wir eine neue Firmware schreiben mit welchem Workaround / welcher Lösung auch immer. Die Knoten bleiben ja trotzdem dann dort, wo sie stehen. Hilft halt eher nur für künftige Knoten, und diese Problematik halte ich für überschaubar bzw. lösbar.
Ich wäre tatsächlich dafür die Knoten aufzuspüren und unschädlich zu machen. Ich helfe auch gerne.
Eine App wär nicht schlecht, die anzeigt, ob Knoten in der Umgebung sind, die z.B. noch auf dem falschen Kanal senden, oder über die keine DHCP Replys kommen.
Let’s play seek and destroy.
Na klar hilft das: Dann richten diese Knoten nämlich schlicht keinen Schaden mehr an indem sie NutzerInnen anziehen, die dann dort kein Internet bekommen (was sie eigentlich erwarten würden.)
Und zu sagen „Wir bauen aber doch kein ‚Abschalt-Konzept‘ in neu zu installierende Router ein“(„lass sie uns lieber so bauen, dass sie gar nicht offline fallen können“):
Frommer Wunsch! Und Blauäugig!
Das entspräche dem Verhalten von Konsumgüter-Produzenten, die sich jahrelang geweigert haben, Entsorgungskonzepte (für das "End of Life-Szenario) in Produkte mit hineinzudesignen. Frei nach dem Motto: „Wir können bei einem neuen Gerät doch in die Bedienungsanleitung nicht hineinschreiben, wie man das Ding wegwerfen soll!“.
Doch kann man, sollte man, muss man!
Dass es dann hinterher noch ein 2nd life geben kann nach einem Refurbishment oder einem echten Recycling auf Baugruppen-Ebene oder durchlaufen eines Reparaturcafes: Unbestritten. Aber ein Gerät da ist, dafür muss vorgesorgt sein, für eben den leider üblichen Worst-Case.
Und das brauchen wir für die Freifunk-Touter auch.
Wenn es am Ort einen Pebrille gibt, der Haftnotzizen aus Haustüren klebt und BewohnerInnen anspricht, ob sie wüssten, wo „dieser Freifunk-Router“ steht: Been there, done that. Aber wenn nicht, dann muss es einen Default-Plan geben der bis dahin greift. Oder eben allein wirksam ist, wenn sich niemand vor Ort findet, der abandonned FF-Router jagt.
Ich rede von bereits aktiven Knoten, nicht von Knoten die in Zukunft verwaisen werden. Nur für Knoten die nach der Implementierung dieser Lösung installiert werden, hülf dieser Ansatz.
Blauäugig? Ich? Nein. Ich denke nur, dass wir möglichst wenig unnötige Komplexität in die Firmware bringen sollten. Die Komplexität und auch das Fehlerpotential der Firmware zu erhöhen, muss überdacht werden. Da wollte ich anregen drüber nachzudenken. Hinzu kommt, dass solch eine Lösung auch möglichst zukunftssicher für künftige Gluon-Versionen sein sollte, sonst müssen wir für dieses Feature immer nachimplementieren. Dass Gluon diesen Ansatz von Haus aus mit aufnimmt halte ich nach jetzigem Gefühl nicht für wahrscheinlich.
Ich glaube einer der tiefgehendsten Probleme die wir mit dem Freifunk haben ist, dass wir das als bürgerlich betriebenes Netz betrachten. Nur leider sind die Bürger nur formell Betreiber, und in aller Regel nicht administrativ. Da find ich es viel blauäugiger zu glauben, man könne ein Netz dauerhaft am Funktionieren halten, ohne dass es für die Knoten Admins gibt. Die Freifunk Firmware ist ja mit Gluon schon wirklich ein Stück gereift, aber zu glauben wir hätten hier die eierlegend Wollmilchsau (im Sinne von: „ist so gebaut, dass sie immer funktioniert, und wenn nicht, dann wenigstens nicht stört“), ist nicht realistisch.
Korrekt.
Die Vergangenheit kann niemand ungeschehen machen.
Aber man kann ja lernen für die Zukunft.
(Und die Altlasten musst man dann eben jagen oder als solche schlicht verdrängen plus das Argument bringen, dass „gute Mobil-Betriebsysteme“ damit umzugehen wüssten. Getreu dem Motto „schmeisst die alten Androids weg wo es keine Updates mehr gibt oder kauft gleich Apple“)
Kannst Du jene Skripte veröffentlichen? Auch mit dem Gluon-Feature „Private WLAN“ laufen wir in eine doofe Falle: jenes Netz wird auch ohne Uplink gestartet, somit haben wir bestenfalls private WLAN ohne Verbindungen …
Ich frage tatsächlich nur ab ob der Knoten in der Lage ist einen Gateway zu finden. Üblicherweise schalten damit Knoten um die keinen VPN Uplink und keinen passen Mesh Partner in Reichweite haben.
Wir können aber aber wenn es eine Störung auf den Supernodes gibt auch den gw Modus auf den Supernodes deaktivieren um die Änderung zu triggern.
Das würden wir sicherlich machen wenn über längerer Zeit der Uplink ins Internet gestört ist.
Damit hast du also recht, vor gut einem Jahr als ich die Diskussion begonnen habe gabt es das bei uns aber nicht nicht. @RubenKelevra hatte es aber tatsächlich auch damals schon für die VfN Knoten:
Den Output hab ich dort ja gepostet. Aber ich hab jetzt einfach mal probiert die firmware doch ganz zu bauen und nicht nur das modul zu kompilieren… hat anscheinend geklappt! Das heisst, es ist nur irgendwas seltsam, wenn man das modul allein compilieren will mit
make package/gluon-ssid-changer/compile V=s
werd die jetzt mal ausprobieren und damit rumtesten, ob ich das schaffe, statt die SSID zu ändern eine zusätzliche SSID mit der warniung aufzubauen
Wie auf github schon von anderer Stelle kommentiert, die Idee des ssid-changers ist es eigentlich, die Verbindung mit dysfunktionalen WLANs zu verhindern (okay, typischerweise gibt’s ohne Link eh’ keine DHCP-Antworten, d. h. automatisch verbinden sich mit solchen Knoten eh’ keine aktuellen Geräte), auch, wenn jemand das manuell probiert (weil er die lokale Freifunk-SSID sieht).
Welchen Sinn es haben soll, im Fehlerfalle statt die FF-SSID in „… tut nicht“ zu ändern, eine zusätzliche mit dieser Information hochzufahren, erschließt sich mir ehrlich gesagt nicht. Das würde nur Sinn machen, wenn man über ULA-Adressen arbeitete in einem kleinen Mesh mit nur einem Uplink ins große Mesh, oder übersehe ich was?
Es macht schon Sinn, wenn man einen funktionierenden und einen nicht funktionierenden Knoten nebeneinander hat. Bei einem Handover bei gleicher SSID fragt der Client nicht noch einmal nach einer IP. Es gehen nur plötzlich und für den Benutzer nicht erkennbar keine Daten mehr durch und frustet diesen.
Man könnte es auch anders aufziehen, indem man im Normalfall eine „Freifunk-mit-Internet“ und eine „Freifunk-ohne-Internet“ SSID hat. Dann schaltet man einfach im Störungsfall die „Freifunk-mit-Internet“ ab.
Die meisten Benutzer klicken sicher nicht auf die „ohne Internet“. Wer aber Freifunk-Poweruser ist, kann sich zu der „ohne Internet“ verbinden, und wird dann auch bei flatternden Uplinks nicht in seinen internen Verbindungen gestört.
die Transfer-Quality-Grenzen (TQ) ersetzt durch einen einfachen check, ob gateways erreichbar sind (idee von @fuzzle)
einen optionalen Timeframe eingebaut um die Offline-SSID z.b. maximal einmal pro tag zu aktivieren.
So werden praktisch keine Vebindungen gekappt, sondern nur Knoten dauerhaft umgeschaltet, die ein Problem haben, oder doof in der Gegend stehen ohne Netzanschluss, weil den mal jemand unachtsam getrennt hat.
