Regio Aachen Experimental Branch mit offline-ssid-changer

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.

https://images.aachen.freifunk.net/beta/

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

Die Beta wird noch nicht per Autoupdater verteilt, da möchte ich erst noch das Feedback auf dem morgigen Community Treffen abwarten:
http://freifunk-aachen.de/event/community-treffen-aachen/?instance_id=385

Ich würde mich sehr freuen wenn einige das Update schon manuell installieren würden, download direkt auf den Knoten ist möglich von Freifunk Regio Aachen - Firmware 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

1 Like

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:

Okay, ein erstes Problem habe ich schon gefunden.

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.

1 Like

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.

1 Like

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.

1 Like

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).

1 Like

Danke für den Hinweis, ich habe hier kein Privates WLAN deshalb ist mir das nicht aufgefallen:
https://github.com/ffac/gluon-ssid-changer/blob/master/files/lib/gluon/ssid-changer/ssid-changer.sh

An sich wollte ich stur jegliche ssid überschreiben falls es zuvor zu fehlen gekommen ist, das war der der Verwendung von uci auch noch sinnvoll.

Ich baue jetzt erstmal eine neue experimental, für die Beta warte ich bis heute Abend auf Feedback.

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:

2 Likes

Prima! Ich werde das dieser Tage mal ausprobieren…

Ich hab auch mal auf experimental umgestellt

Also bei mir startet fastd nicht mehr nach dem Update. Auf zwei Geräten (C5 und 841).

Tue Oct 13 18:22:45 2015 daemon.err fastd[1168]: config error: method `salsa2012+umac' not supported
Tue Oct 13 18:22:45 2015 user.emerg syslog: /etc/rc.d/S95fastd: mesh_vpn: startup failed

Nachdem ich von salsa2012+umac auf null umgestellt habe funktioniert es wieder.

Interessant, kann das jemand bestätigen?

Mein 841er verbindet sich normal.

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 :frowning:.

Solange nicht noch ein funktionierender Uplink im Mesh ist.