Bitte respektieren und in einem anderen Thread diskutieren!
1 „Gefällt mir“
wir in freiburg haben den ganzen teil mit der TQ raus genommen und damit das ganze um einiges entschlackt,
es wird nur die Bedingung „Verbindung zu einem Batman Server“ getestet und ausgewertet.
Same here. Wenn „Dienst Internet“ nicht verfügbar, Schwenk auf FF_OFFLINE_AABBCC. Aktuell noch kleines Manko beim Reboot: Config setzt FF-SSID, cron kommt, findet keinen Link (fastd dauert ein bißchen) und stellt auf FF_OFFLINE, nächster Cron-Lauf setzt dann (i. d. R.) wieder auf FF-SSID. Können wir mit leben …
Was derzeit als Erweiterung im Raum steht: statt FF_OFFLINE_AABBCC (Teil der MAC am Ende also) einen genaueren Fehlercode auszugeben: FF_OFFLINE_LINK (WAN ohne Link), FF_OFFLINE_VPN (WAN hat IP/Link, aber wir keine Verbindung ins Mesh => wohl Portfilter oder kein funkionales Internet), … Denn während wir viel lokal auf dem Knoten ermitteln können, wenn’s nicht tut, sehen wir von außen nix, außer ggf. eben die Offline-SSID. Mit spezifischeren Offline-SSIDs könnte man aus der Ferne Ratschläge zum Debugging geben …
Hä? Alle vier Antworten, abgesehen von SSID-changer optimieren (gluon-ssid-changer forks merged) - #5 von rubo77 vielleicht, bezogen sich nicht auf die Sinnhaftigkeit, sondern primär auf’s Timing, was die initiale Frage war: »Ich denke, es wäre sinnvoll wäre, das stattdessen von der Router uptime abhängig zu machen entweder einmal gleich nach dem systemstart, oder halt das erste mal erst nach 24h. Was wäre sinnvoller?«
2 „Gefällt mir“
Es wäre in der Tat sinnvoll mit der offline SSID zu booten, daher habe ich es damals nicht eingebaut.
Mit cron lässt sich das nicht realisieren, mittels init.d sollte es sich aber machen lassen.
2 „Gefällt mir“
Naja, wie oft bootet man einen Knoten? Und bei Meshing tritt das Problem eher nicht auf, und bei uns eher stärker beim VPN, da wir relativ viele GWs vorgesehen haben, von denen nur zwei derzeit auch aktiv sind. Kurz: Randbedingung, die gut verstanden ist und imho den Aufwand nicht lohnt. Ist halt beim Aufstellen erklärungsbedürftig, danach merkt es kaum noch jemand 
Wäre aber ein Punkt, den man verbessern könnte, daher sprach ich’s an. Aber den Fehlergrund darüber zu kommunizieren liegt mir mehr am Herzen …
Ich hab mal eingebaut, dass unser SSID-changer während der ersten 5 Minuten jede Minute schaut, ob der Router offline ist, und während dieser ersten 5 Minuten dann immer die OFFLINE-SSID setzt:
danach wird der dann wie bisher höchstens einmal am Tag wieder die OFFLINE SSID setzen, wohingegen wie bisher jede Minute zurückgesprungen werden kann auf die normale SSID
1 „Gefällt mir“
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?