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)
1 „Gefällt mir“
ü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
Warum sollte das nicht kompatibel sein? Ich sehe da keine Probleme. Müsste man Mal testen.
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.)
2 „Gefällt mir“
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
4 „Gefällt mir“
Konfiguration per site würde mir auch sehr gut gefallen, konkret sinnvoll fände ich:
offline_ssid
einheitliche offline_ssid #Es gibt communities die den Knotennamen nicht in der offline_SSID haben
TQ_min
TQ_max
Naja, dann halt noch die variable um das offline schalten zu verzögern…
Wir in Bochum nutzen den ssid changer auch modifiziert. er wechselt auch Freifunk_OFFLINE
[
bitte editert mal alle in euren kommentaren das „bei uns“ zu " in Freifunk xyz …" 
3 „Gefällt mir“
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
},
},
hab ich irgendwas vergessen?
Welche Fehlerzustände könnte man denn erfassen für die Offline-SSID?
- status Wan eth (link, dhclient hat lease)
- VPN-server resolven, sind anpingbar
- batctl¦wc - l und zusätzlich noch auf vpn, radio0/1 lan/Wan heruntergebrochen?
und wie jetzt diesen Haufen Infos platzsparend tokenisieren und per uuencode in die SSID
Ich habe die erste funktionierende Version fertig:
Alle optionen sind in der site.conf einstellbar und mit uci änderbar
(TODO: den tq-level von ffac noch einbauen)
3 „Gefällt mir“
wollt mich nochmal einklinken, coole Intention -
wollt nur einwerfen, das Komplex mitunter auch Groß bedeutet,
hast du dir dazu gedanken gemacht?
bytes filename
50 usr/lib/micron.d/ssid-changer
23 etc/config/ssid-changer
3557 lib/gluon/ssid-changer/ssid-changer.sh
701 lib/gluon/upgrade/500-ssid-changer
ist das gross?
jenachdem wieviel platz du noch hast auf den 4mb kisten, da macht 1kb oder 4,3kb vielleicht schon nen unterschied
wenn ich den code minifiziere, dann ist der wwahrscheinlich nur noch 1/3 so gross, ohne kommentare und einstellige variablen
ja wollt dir das nurfür den hinterkopf mitgeben, weil ich vor nem jahr ganz schön strauchelte mit feature foo aus Platzgründen bei uns in Freiburg
einfach den DIR615 rausswerden, dann kompiliert es wieder durch…
Ich habe den aachener ssid-changer und den von Freifunk Nord gemerged zu einem paket:
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
1 „Gefällt mir“
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)