SSID-changer optimieren (gluon-ssid-changer forks merged)

Es war noch ein Fehler im check, wie oft der Knoten offline war.

Im letzten release gehen die Knoten jedesmal nach ablauf des switch_timeframes einmal offline für eine Minute.

Neue Releases für 2016.2.x und 2017.1.x sind raus die das fixen:

1 „Gefällt mir“

Gibt es eine Einstellung, damit der SSID-changer nicht im config mode unter 2017.1.x auftaucht?

1 „Gefällt mir“

Könnte man einfach einbauen, aber warum wollte man denn verstecken?

Die Community will den als „Pflicht“ in der Firmware :wink:

Er hat sich halt bewährt. Und wenn er nicht an ist, dann hängen früher oder Später wieder „Leichen“ rum, die kein Freifunk anbieten aber die SSID dies vermuten lässt. Von der Diskussion, was Freifunk ist, mal abgesehen :slight_smile:

3 „Gefällt mir“

Eine Einstellung will ich jetzt nicht einbauen, aber ihr könnt ja einfach den lede branch klonen und den Ordner

 /gluon-ssid-changer/luasrc/lib/gluon/web/

löschen, das müsste reichen.

Für den 2017.1.x lede branch gab es einen BUG: Der ssid-changer war anscheinend bisher bei Neuinstallationen default aus. Nur beim upgrade hat er den angeschlateten Status erhalten.

Im neuesten Commit ist der ssid-changer jetzt immer default an und man kann ihn im Config mode de- oder aktivieren.

Außerdem habe ich einen neuen branch angelegt für den aktuellen master: Branch 2018.1.x

4 „Gefällt mir“

Huston, we have a problem:

hat das jemand mal richtig durchgetestet? Ob die Werte aus der site.conf übernommen werden?



Es gibt einen neuen commit. bitte mal testen ob das gefixt ist.

1 „Gefällt mir“

Der SSID changer unterstütz hetzt auch Communities, die auf 2.4 und 5 GHz verscheidene SSIDs betreiben:

3 „Gefällt mir“

irgendwie finde ich deine branch-namen verwirrend, sie benutzen drei verschiedene schemata…
ich würde erwarten, dass der master branch das aktuellste Gluon master supported, und es dann branches für die stable releases gibt namens v2016.2.x und v2017.1.x …
ich habe erst nach etwas nachdenken aber schon irgendwann verstanden, welcher eurer branches für welches Gluon release ist

ja, find ich auch unglücklich, aber ich hatte am Anfang nur den master und der war für 2016.x, wenn ich den namen jetzt ändere, dann knallt das bei vielen, die den master-branch noch benutzen.

Deshalb werde ich den master jetzt in 2016.x umbenennen und den lede in 2017.x. dann ist es einheitlich

Anscheinend initialisierte der ssid-changer bisher nicht auf Knoten mit der neuen master-firmware!

Es gibt jetzt ein wichtiges Update für den 2018er branch 2018.1.x:

1 „Gefällt mir“

Mit diesem Commit Funktioniert die deutsche ansicht des SSID-Changer Menus im Config mode auch wieder.

Zur info: die version des ssid-changers im „eulenfunk/packages“ Repo ist entfernt worden und dort wird jetzt auch der aus dem Repo von Freifunk Nord benutzt.

3 „Gefällt mir“

Seit, hmm, Gluon v2020.2 gibt’s ja ggf. zwei AP-SSIDs je Radio, die ›klassische‹, unverschlüsselte, und eine mit OWE (WPA3). Bislang werden AFAICS nur die ›klassischen‹ SSIDs umgestellt — hat sich das jemand schon mal angesehen? Ich würde vorschlagen, die OWE-SSIDs einfach abzuschalten, wenn die Offline-SSID aktiviert wird — zwei Offline-SSIDs erscheinen mir nicht zielführend :wink:

1 „Gefällt mir“

Davon ab wäre das Nutzen der gluon-state-check-Infrastruktur eine gute Idee, um unnötige Abfragen in’s Netz zu vermeiden.

@fmaurer hatte die Idee schon vor ein paar Wochen:

… in Gluon v2020? Erzähle gerne mehr!

Augenscheinlich ja: https://github.com/tecff/gluon-packages/tree/main/tecff-ssid-changer

Damit brichst du im Falle des Transition-Modes sämtliche Verbindungsversuche für Clients die das pointer-IE im unsecured beacon sehen. Beide Netze zeigen auf sich gegenseitig, daher musst du zwar nur die SSID des unsecured netzes anpassen, aber ebenso den pointer im OWE beacon.

Ist das auch relevant hierbei?

  owe_transition_mode = false,

(Da die Berichte eher in Richtung »nice try, but at times badly implemented« gingen, haben wir den disabled.)

1 „Gefällt mir“

Nein

1 „Gefällt mir“

Ah ne. Ich sprach von supporteten Releases, sorry.

Aber das Paket ist relativ gut isoliert, ein Backport des einen Commits, der die Infrastruktur schafft ist vmtl. trivial.
Wenn sich jemand an das Paket setzt, sagt gerne Bescheid, beim Backport helfe ich gerne.