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

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 :wink: »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 :wink:

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:

https://github.com/Freifunk-Nord/gluon-ssid-changer/blob/lede/gluon-ssid-changer/files/lib/gluon/ssid-changer/ssid-changer.sh#L54

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)

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.

Wie lange dauert es denn, bis die TQ auf 0 sinkt? Bei

mcast_rate = 12000,

0 wird ja gar nicht gebraucht, sondern nur der „min-tq-wert“, Und das sind hier ca. 2-3 Minuten (nach meinem Gefühl, nicht gemessen.)

Ich frage, weil ich ungern eine, wenn auch nur noch so schwache Verbindung trennen will, über die vielleicht gerade mal noch ein ping geht.

Deshalb würde ich die min-tq auf 0 setzen wollen, so dass erst, wenn diese wirklich erreicht ist, der router offfline schalten würde.

Also sinkt die TQ nach 3 mniuten auf komplett 0?

ausprobieren geht über raten :wink:

1 „Gefällt mir“

Ich hab das issue so umgesetzt. Bitte mal testen, ob das bei euch so läuft, wie es soll.

zum Testen kann man den auch von Hand installieren:

DEFAULT_TIMEFRAME=30
DEFAULT_FIRST=5
ROUTER_IP='your:node::ip6'
LOGIN="root@[$ROUTER_IP]"
git clone https://github.com/Freifunk-Nord/gluon-ssid-changer.git ssid-changer
cd ssid-changer/gluon-ssid-changer/
git checkout master
scp -r files/* $LOGIN:/
scp luasrc/lib/gluon/upgrade/500-ssid-changer $LOGIN:/lib/gluon/upgrade/
ssh $ROUTER_IP "/lib/gluon/upgrade/500-ssid-changer;" \
  "uci set ssid-changer.settings.switch_timeframe='$DEFAULT_TIMEFRAME';" \
  "uci set ssid-changer.settings.first='$DEFAULT_FIRST';" \
  "uci commit ssid-changer;" \
  "uci show ssid-changer;" \
  "/etc/init.d/micrond reload;"
1 „Gefällt mir“

Ich habe jetzt versucht, den ssid-changer nach 2016.2.x zu portieren, aber komme da nicht weiter.

Beim Bauen des aktuellen master Branches des ssid-changer mit Gluon 2016.2.x kommt der Fehler, das der Ordner luadest/*nicht existiert.

Kann mir da jemand weiter helfen?

Oder brauchen wir den eh nicht mehr lauffähig für das alte Gluon?


Update: Ich hab jetzt mal den GluonDiet Kram rausgenommen und dann klappt das bauen der 2016.2.6 auch!

Die neue Version hat jetzt einen Bereich im Admin Interface, wo man den ssid-changer dis-/enablen kann:

lol „Verbundung“ :wink:

…wird korigiert

2 „Gefällt mir“