Hoodselector tarek
Ich hab heute den Tag über den hoodselector umgeschrieben. Er verhält sich jetzt folgender maßen: Sei eine Anzahl von n Mesh-Routern auf einer Fläche, mit jeweils unterschiedlichen BSSIDs und keiner Erreichbarkeit von Supernodes verteilt. So sollen diese Router versuchen möglichs eine meshwolke mit zu bilden. Bekommt ein Mesh-Router nun eine Internetverbindung und somit eine Verbindung zu einen Supernode Wechselt dieser Router automatisch in seine gehörige Hood mit entsprechender BSSID. Lokale Mesh Router Würden die geänderte bssid sehe und diese übernehmen. Besitzt einer der Router nicht die zugehörige hood zur bssid so schaltet dieser den fastd ab. der Router holt sich über den Nachbar Router nach einiger zeit selbständig die neuen hoodinformationen und schaltet den fastd wieder ein sobald dieser die passenden hoodinformationen besitzt.
Merge request reports
Merged by
(Mar 21, 2025 1:54am UTC)
Activity
Hi,
dieser Merge-Request macht die Annahme, dass es Internet gibt indem die Existenz eines VPN vorausgesetzt wird und die Korrektheit der erhaltenen Koordinaten nur bei Existenz eines VPN gegeben ist. Diese Annahmen treffen auf Freifunk Nordwest zu, können meiner Meinung nach aber nicht verallgemeinert werden.
Denn...
- ...man kann ein Freifunk Netzwerk grundsätzlich ohne VPN bauen sodass das Prüfen eines VPN-Zustandes im Programmfluss nicht erlaubt ist. Das selbe gilt für das Prüfen von optionalen Diensten (z.B. Batman advanced Gateway).
- ...korrekte Koordinaten können manuell gesetzt werden sodass der Hoodselector erhaltene Koordinaten nicht ignorieren darf.
Die bisherigen Vorschläge gehen immer davon aus, dass es grundsätzlich Internet gibt. Genau davon gehen wir bei Freifunk aber nicht aus weshalb der Hoodselector im Programmfluss nur Informationen nutzen sollte, die immer und jederzeit vorhanden sind:
- Inhalt der hoodlist
- Erhaltene Koordinaten
- Ergebnis von
iw <radio> scan
Die Liste ist unvollständig. Es gibt sicher noch weitere Informationen die in einem Freifunk Mesh Netzwerk jederzeit vorhanden sind. Ein paar die mir noch einfallen sind:
- Zustand der vorhandenen Interfaces (WLAN interfaces und LAN interfaces)
- Existenz von Mesh-Nachbarn
- ...
Nicht geprüft werden sollten wie gesagt Dienste, die Optional sind. Dazu gehört idR. alles was irgendwie mit Internet zu tun hat.
Added 1 commit:
- 39f57dc5 - Fix sed command parameters
Die VPN prüfung könnte auch durch prüfung auf "ist der nächste hob ein batman GW" aber das ist in diesen falle egal das der hoodselector u.a. nenau die aufgaben vertritt die VPN config anzupassen. Zudem hat die VPN prüfung nix mit internet zu tuhen sondern prüft imgrunde einfach auf eine direkte supernode verbindung. Ich halte eine abstraktion die keine anhänginkeit dinsen wir batman hat für aktuell unnötig und kann bei wehniger zeitdruck nach gebessert werden.
Diese variante des hoodselectors ist extra so geschrieben dass keine prüfung auf Internet kornektivität besteht sondern. Eben versucht einzelne router möglichts in eine meshwolke zubekommen unabhängig vom Internet. Bekommt ein Router eine verbindung zum supernode hin (nicht zum internet) so wechselt der router in die hood des zugehörigen supernodes.
zu der liste gehören auch fastd (VPN) und batman (mesh protokoll) <-- die diehenen in unseren Freifunk netzt dazu die Router zusammen zuführen sowohl lokal vorort als auch virtuell via VPN. Internet in in diesem Punkt nicht Relevant und wird ausschließlich optional als service von einzelnen Supernodes gestellt.
386 io.stderr:write('Setting defaulthood.\n') 387 exit() 388 end 389 io.stderr:write('Error while setting defaulthood.\n') 390 exit() 391 end 392 end 393 io.stderr:write('Router dont have a position.\n') 394 end 395 396 if next(radios) then 397 -- If no direct VPN and batman GWs not in range set scanned bssid 398 local scanBssid = getNeigbourBssid(radios) 399 if scanBssid ~= nil then 400 if not getGwRange() then 401 if setHoodWifi(scanBssid,radios) then -
Hier wäre mein vorschlag der scan function eine zu preferierende BSSID mit zugeben, die zuvor via geokoordinaten aus den hoodfile ermittelt wurden. Das sorgdafür das wenn die übergebene BSSID um umfeld zu sehen ist, diese bevorzugt wird. Grund dafür ist das laut Clemens der schwerpunkt auf die geokoordinaten gelegt werden soll.
-
Ich akzeptiere den Merge-Request wie besprochen. Allerdings sollte der Hoodselector so nicht produktiv gehen, da es mehrere Punkte gibt die wir uns vorher ansehen sollten:
- Code vereinfachen. Z.B.
- Methode getNeigbourBssid: ob ich jetzt alle 5 Minuten den RAM für 10 Sekunden oder für 3 Minuten belege ist wurst. Der RAM für das Skript muss zur Verfügung stehen und dann kann man die Verbindung auch in einer For-Schleife prüfen. Das ist vom Quellcode verständlicher und erleichtert das debugging allgemein
- ...gibt sicher noch mehr stellen, aber über die obige haben wir explizit gesprochen
- Vor einer Rekonfiguration des WLAN muss das VPN immer abgeschaltet werden
- Wenn sich der Router zu einer beliebigen Hood verbindet muss das VPN auch in der UCI-Config ausgeschaltet werden sonst sorgt ein reboot für das Verbinden zweier Hoods
- Wenn alle Modi fehlschlagen, sollte der Router in der Default-Hood landen
Ich schaue mal, dass ich ein paar Änderungen bis 12 Uhr direkt umsetzen kann
mentioned in commit 3b1a9c1e
mentioned in commit 6ac3ccb5