Ich bin geradde dabei den SSID-Changer zu optimieren, den wir in Freifunk Nord schon erfolgreich nutzen seit einem Jahr:
Ich möchte hier nicht diskutieren über sinnvoll oder nicht, so eines Dienstes, sondern nur über die Weiterentwicklung.
Wir haben den bisher so eingestellt, dass er maximal alle 24h einmal auf die OFFLINE SSID stellt, wobei dies im Moment immer Mitternachts passiert.
Ich denke, es wäre sinnvoll wäre, das stattdessen von der Router uptime abhängig zu machen entweder einmal gleich nach dem systemstart, oder halt das erste mal erst nach 24h.
Erst nach so unglaublich langer Zeit zu schalten ist bei euch politisch gewollt, alternativ gäbe es schlicht keinen ssid changer in eurem Netz?
Ein durchlauf kurz nach dem Start wäre da sicherlich eine sinnvolle Ergänzung.
Ich überlege momentan bei uns eine Anpassung vorzunehmen, die das umstellen auf die offline ssid per wifi Kommando umsetzt, dass sollte einige abgestürzte Knoten wiederbeleben.
Bei uns passiert das sofort. Innerhalb weniger Minuten. Kommt eigentlich sehr gut an und wir sind sehr zufrieden damit. Gerade weil die Telefone schnell aus dem WLAN fliegen und dann wieder online sind. Nichts nervt die Leute mehr, als wenn sie offline und nicht erreichbar sind.
Glaub der wird alle paar Minuten ausgeführt bei uns.
Ich verstehe die Logik nicht, das nicht zeitnah zu tun, also Prüfung alle Minute (mit 5min Verzögerung nach Start).
Und ja, die TQ zum bat-gateway ist bereits träge genug, um einem Flapping vorzubeugen.
wir in freiburg haben den ganzen teil mit der TQ raus genommen und damit das ganze um einiges entschlackt,
es wird nur die Bedingung „Verbindung zu einem Batman Server“ getestet und ausgewertet.
Same here. Wenn „Dienst Internet“ nicht verfügbar, Schwenk auf FF_OFFLINE_AABBCC. Aktuell noch kleines Manko beim Reboot: Config setzt FF-SSID, cron kommt, findet keinen Link (fastd dauert ein bißchen) und stellt auf FF_OFFLINE, nächster Cron-Lauf setzt dann (i. d. R.) wieder auf FF-SSID. Können wir mit leben …
Was derzeit als Erweiterung im Raum steht: statt FF_OFFLINE_AABBCC (Teil der MAC am Ende also) einen genaueren Fehlercode auszugeben: FF_OFFLINE_LINK (WAN ohne Link), FF_OFFLINE_VPN (WAN hat IP/Link, aber wir keine Verbindung ins Mesh => wohl Portfilter oder kein funkionales Internet), … Denn während wir viel lokal auf dem Knoten ermitteln können, wenn’s nicht tut, sehen wir von außen nix, außer ggf. eben die Offline-SSID. Mit spezifischeren Offline-SSIDs könnte man aus der Ferne Ratschläge zum Debugging geben …
Hä? Alle vier Antworten, abgesehen von SSID-changer optimieren (gluon-ssid-changer forks merged) - #5 von rubo77 vielleicht, bezogen sich nicht auf die Sinnhaftigkeit, sondern primär auf’s Timing, was die initiale Frage war: »Ich denke, es wäre sinnvoll wäre, das stattdessen von der Router uptime abhängig zu machen entweder einmal gleich nach dem systemstart, oder halt das erste mal erst nach 24h. Was wäre sinnvoller?«
Es wäre in der Tat sinnvoll mit der offline SSID zu booten, daher habe ich es damals nicht eingebaut.
Mit cron lässt sich das nicht realisieren, mittels init.d sollte es sich aber machen lassen.
Naja, wie oft bootet man einen Knoten? Und bei Meshing tritt das Problem eher nicht auf, und bei uns eher stärker beim VPN, da wir relativ viele GWs vorgesehen haben, von denen nur zwei derzeit auch aktiv sind. Kurz: Randbedingung, die gut verstanden ist und imho den Aufwand nicht lohnt. Ist halt beim Aufstellen erklärungsbedürftig, danach merkt es kaum noch jemand Wäre aber ein Punkt, den man verbessern könnte, daher sprach ich’s an. Aber den Fehlergrund darüber zu kommunizieren liegt mir mehr am Herzen …
Ich hab mal eingebaut, dass unser SSID-changer während der ersten 5 Minuten jede Minute schaut, ob der Router offline ist, und während dieser ersten 5 Minuten dann immer die OFFLINE-SSID setzt:
danach wird der dann wie bisher höchstens einmal am Tag wieder die OFFLINE SSID setzen, wohingegen wie bisher jede Minute zurückgesprungen werden kann auf die normale SSID
Wie wenig sinnvoll das eventuell sein könnte haben andere bereits andere oben diskutiert.
Wobei meiner Meinung nach, dass besser über uci&site.conf konfiguriertbar sein sollte.
Auch der Threshold für für die Verbindungsqualität zum gewählten Batman-Gateway.
(Und ja, dass es auch Communities gibt, die eine TQ von 2 zu einem Gateway für ausreichend halten: Habe ich verstanden. Und auch, dass Probleme nicht zwangsläufig lokal sein müssen in mehrstufigen Meshes)
über uci&site.conf konfiguriertbar sein sollte.
Auch der Threshold für für die Verbindungsqualität zum gewählten Batman-Gateway.
Über die Site.conf wäre schön, aber hast du ein Beispiel, was an UCI besser wäre, als wenn man in der Datei die Werte oben ändert? Einsatz Szenario?
Wer würde das nutzen? Und warum?
TQ Messung haben wir in Nord ja rausgeschmissen: nur, wenn Gateway Weg ist, setzt er die offline ssid
Da sagtest Du. Mag bei Euch sinnvoll sein, bei in ffdus gibt’s halt auch Linkstrecken, die mal bei Regenwetter (Bäume derzeit mit Laub) auf unnutzbare 1% zusammenbrechen (Also Packetloss >90%) und erst nach etwas Abtrocknen wiederkommen.
(Daher auch ein 24h/Mitternachts-Check nicht sinnvoll.)
Wir könnten den Aachener ssid-changer und den aus Nord Mergen und alles per site.conf und UCI konfigurierbar machen um den ganzen Kram upstream zu bringen als Paket
Wäre aber ein Punkt, den man verbessern könnte, daher sprach ich’s an. Aber den Fehlergrund darüber zu kommunizieren liegt mir mehr am Herzen …