Warum sollte die SSID einheitlich sein? In einem Mesh möchte ich evtl. ja wissen, welcher Knoten gerade Probleme hat. IIRC setzt Ihr ja den Knotennamen mit rein, das halte ich aber für unschön (»FF_OFFLINE_33428-StadtHSW-FU-Schwesterngarten-1«? Gruselig »FF_OFFLINE_30b5c2b0321c« finde ich schöner und weniger einladend, sich damit verbinden zu wollen.) und auch unnötig; eigentlich sollte man die SSID gar nicht sehen, denn sie ist ja mehr oder minder nutzlos (auch »lokale Dienste« werden kaum funktioniere, es sei denn, sie hängen just hinter dem Knoten). Andererseits ist es auch ein Hinweis auf »Technik hakt gerade, aber eigentlich sollte es bald wiederkommen«. Anyway, unsere (Kreis GT/Müritz) Offline-SSID wird so gebildet:
# Offline-SSID is just Prefix+PrimaryMAC
OFFLINE_SSID="${OFFLINE_PREFIX}`/bin/cat /lib/gluon/core/sysconfig/primary_mac | sed -e 's/://g'`"
Aber, wie gesagt, an sich soll da bei uns noch ein Indikator rein, warum es wohl nicht tut., sprich die kodierte Info, ob WAN-Link da ist, WAN über IPv4- und/oder IPv6-Adresse verfügt (v6 != link-local), WLANs gesehen werden; noch was?
Derzeit ist es einfach unbefriedigend, wenn es beim Knotenaufbauen nicht klappt und man nur zu hören bekommt »ja, klar, alles angeschlossen und freigeschaltet, aber das tut nicht«. Mit der Info »habe Link, aber keine (v4-) IP« über die Offline-SSID könnte man aus der Ferne gleich sagen »check mal die Firewall/den DHCP-Server« … bzw. auch den Aufstellern vor Ort Hilfestellung geben (die »Codes« sollte dokumentiert sein).
Ich habe mal einen Entwurf für die site.conf einstellngen gemacht:
ssid_changer = {
switch_timeframe = 1, -- only once every timeframe (in minutes) the SSID will change to OFFLINE
-- set to 1440 to change once a day
-- set to 1 minute to change every time the router gets offline
first = 5, -- the first few minutes directly after reboot within which an Offline-SSID always may be activated
prefix = 'FF_OFFLINE_', -- use something short to leave space for the nodename (no '~' allowed!)
suffix = 'nodename', -- generate the ssid with either 'nodename', 'mac' or to use only the prefix: 'none'
limits = {
disabled = false, -- if true, the offline ssid will only be set if there is no gateway reacheable
-- upper and lower limit to turn the offline_ssid on and off
-- in-between these two values the SSID will never be changed to preven it from toggeling every Minute.
tq_max = '55' -- upper limit, above that the online SSID will be used
tq_min = '45' -- lower limit, below that the offline SSID will be used
},
},
Man kann jetzt in der site.conf einstellen, ob man mit upper und lower limit arbeiten will oder ob man nur checken will, ob überhaupt ein Gateway erreichbar ist.
Außerdem kann man unabhängig davon den Timeframe einstellen, wie oft die SSID auf OFFLINE geschaltet werden darf und wie man die OFFLINE SSID generieren will: hostname, mac oder keine Endung
Wir haben noch mal diskutiert, und sind zu der erkenntnis gekommen, dass es nicht so sinnvoll ist, immer gleich sofort offline zu stellen, wenn die Verbindung zum Gateway mal schlecht oder weg ist, sondern dass man längerre Zeiträume untersuchen sollte:
Dazu können wir den „timeframe“ benutzen in dem nicht offline gestellt wird; Jede minute wird ja einmal geprüft, wie die Verbindung zum Gateway ist und dies können wir in einem temp file loggen. Wenn nach ablauf des Timeframes mehr als die Hälfte dieser Tests negativ ausgefallen ist, nur dann schalten wir auf Ofline. Ich hab das hier mal als Issue erstellt:
Jede Community kann ja selbst entscheiden, welchen Timeframe sie einstellen, entweder 1 Minute (das alte Verhalten) Ich glaube ein guter Wert ist, 30 Minuten oder, wie wir in Freifunk Nord, nur ein minimaler Eingriff in die Kontinuität einmal am Tag (für die ganz Vorsichtigen)
die tq zum Gateway ist imho ein sliding value, der über 255*mcast_rate gemittelt wird.
d.h. das Ding rollt normalerweise sowieso über 10+ Minuten.
Um „gleich sofort“ unter den Threshold zu fallen muss es also vorher schon hart der Grenze gewesen sein.
Oder aber jemand hat die mcast_rate auf weniger als 1s gestellt. (Und dann ist die Domain oder der Node vermutlich irgendwas mit „mobilen Knoten“, a la Knoten auf ÖPNV". Und da möchte man eigentlch auch, dass die Clients dann schnell wieder auf 3G/LTE wechseln können.