Nachdem es in den letzten Monaten bei jedem Community Treffen ein Thema war, kann ich nun endlich die erste Beta Firmware mit einem Feature zur Umbenennung der SSID vorstellen.
Das Skript ist sehr einfach gehalten und kommt ganz ohne aktive Checks die die Internetverbindung belasten aus. Es wird lediglich die Link Qualität zum gewählten Gateway ausgewertet, sobald diese unter 50 fällt wird die SSID geändert. Achtung, dies entspricht nicht dem TQ Wert aus der Karte. Die Skala ist hier 0…254
Ich würde mich sehr freuen wenn einige das Update schon manuell installieren würden, download direkt auf den Knoten ist möglich von http://0.updates.freifunk-aachen.de/beta/sysupgrade/ hier den passenden link heraus suchen, dann per ssh auf den Knoten und:
cd /tmp/
wget mit dem link von oben
sysupgrade gluon-ffac-2015.1.2-beta03 und den rest je nach Modell
Verständnisfrage: Der TQ-Wert wird doch mit jedem Hop schlechter, oder? Insofern dass sogar jedes lokale Mesh einen maximalen Durchmesser (im graphentheoretischen Sinne) hat.
Das würde also dazu führen, dass auf den äußersten Knoten bereits das Clientnetz abgeschaltet ist, aber Mesh noch verfügbar ist, oder?
Das ist korrekt, aber bei einem Mesh dieser Größe verliert der äußere Knoten so oder so die Konnektivität zum anderen Ende des Mesh Netwerks, sie auch:
Insbesondere hat dieser Knoten dann aber selbst keine Verbindung mehr zum Gateway.
Ein wirklich guter Mesh Hop (LAN) zieht nur etwa 15 von der ursprünglichen Link Qualität ab ein ordentlich wlan hop 50.
Das betrifft also aus meiner Sicht nur Knoten die es auch betreffen sollte.
Hier direkt ein Beispiel wie es funktionieren kann. Ich habe mit vielen Versuchen und abschalten der Client ssid auf allen Geräten das Update zu den hinteren Knoten durch bekommen.
Sie haben schön die SSID umgeschaltet und 12 User wurden vom nicht funktionierenden Knoten geworden, hoffentlich kommt das Relay bald wieder online, aber zumindest sind die Folgen so eingegrenzt:
Wenn die SSID mittels des kommandos wifi geändert wird wackelt ein mittelmäßiges mesh so stark, dass es sich nicht binnen einer Minute erholt.
Dadurch wird die SSID dann direkt wieder in die Offline SSID verändert.
Es ist möglich das ganze durch ändern von /var/run/hostapd-phy0.conf und killall -HUP hostapd zu realisieren.
@RubenKelevra macht das in seinem Skript so, gibt es keinen anderen Weg das zu schaffen? Auf diese Art hat selbst iw keine Ahnung von der aktuellen ssid.
Ich würde mich freuen, wenn es einfacher ginge als mit Rubens Statemachine.
Ich fürchte nur, dass da schon so viel Erfahrung hinein gereift ist, dass es mit „weniger“ nicht besser laufen wird.
Naja, das Skript stammt wenn ich es recht verstanden habe noch aus vor Gluon Zeiten und einer deutlich instablieres Firmware.
Die aktiven Checks halte ich nicht für Notwendig sofern man seinen Supernodes vertraut bzw bei einem anhaltenden Problem den gw Modus auf den Supernodes abschaltet.
Ich habe auf kill -HUP umgestellt, damit gibt es kein wackeln mehr im Mesh:
Eine neue experimental und v2015.1.2 Beta 04 baue ich jetzt.
Das Problem was ich sehe ist, dass der regelmäßigs Reconfigurieren des At9k zu „komischen“ Zuständen führen kann (no clients, no meshlinks), ohne dass es im Syslog DMA-Phantomfehlermeldunden oder malloc-Paniken gibt.
Dazu passt dann ja das ich mir überlege das ganze zu einem rudimentären watchdog auszubauen.
Etwas in der Art von: 100 mal als offline erkannt, hier stimmt vielleicht was nicht → reboot
Da könnte man dann auch noch einen trigger einbauen, dass bei z.B. bei 40 die ssid auf offline geändert wird, auf online wird aber erst bei 60 gewechselt. Klassischer Schmitt-Trigger.
Ein „immer offline-Konten“ sollte durchaus ohne ständige Reboots stehen bleiben können.
Also maximal ein Reboot pro Tag.
Aber wenn seit Boot zumindest einmal ein gw gesehen wurde, dann würde ich auch sagen: 30min kein gateway? reboot. Und dann erst wieder nach einem tag wenn kein Gateway auftauchen will.
Für Benutzer der Funktion „Privates WLAN“ beim Testen darauf einstellen, dass das Script leider auch dessen SSID auf „FF_OFFLINE_NODENAME“ bzw „Freifunk“ setzt (zumindest beim getesteten Archer C5).
Das ganze hat sich in den letzten Tagen ziemlich weiterentwickelt, wie auf dem Community Treffen abgesprochen bleibt es aber erstmal im Experimental Branch, daher habe ich den Titel auch angepasst. Hier ist der aktuelle Stand, der mit der heutigen gluon-ffac-2015.1.2~2-exp20151012 verteilt wird.
Ich habe mich bemüht den Code auch zu kommentieren:
Bei mir gehts auch nicht. Im Slack haben wir rausgefunden, dass der String „umac“ in der Binary (im Gegensatz zu den alten Firmwares) gar nicht auftaucht.
Verbindest du dich evtl im Wohnheim direkt per LAN mit den Supernodes oder so?
Dazu kommt, dass die Namensauflösung des Autoupdaters nur über die Supernodes geht.
Also die Knoten bekommen auch keine Updates mehr zum Wiederbeleben von uns .
.