Hi,
ich hab heute eine sehr rudimentäre mesh on lan / wan management implementiert.
Das ist z.Z. nicht wirklich anders lösbar, da die network conf in gluon dringend mal von Grund auf neu strukturiert werden muss. Dazu besteht ein eigener milestone im upstream. Das ist so komplex das ich mich die letzten 3 Tage nur mit den networkconf foo und möglichen lösungen beschäftig habe..
Aktuell ist es so das via respondd md5hashes der aktuell gesetzten hoods erstellt werden. Zudem stehen in der section hoodselector auch noch infos wie boolean "vpnrouter", current_bssid und hoodname.
Für das mesh on lan / wan management wird z.Z. nur die hashes verglichen. ist ein hash ungleich zum eigenen wird das mesh on lan wan abgeschaltet...
Es fehlt in gluon leider noch ein flag das mesh on lan oder wan zwingen aus sein soll so das es aktuell immer an ist, bzw. nur aus bei einer Kollision.
Ist eine Kollision fest gestellt worden so wird mesh on lan/wan abgeschalten beim nächsten aufruf den hoodselectors wird diesen aber wieder eingeschaltet da keine kolision mehr ermittelt werden kann (flip flop) beim nächsten Aufruf dann wieder aus usw...
Es gibt zwei Möglichkeiten die ich mir überlegt habe. Die erste wäre die grundlegende überarbeitung der gesamten network conf von gluon was bestimmt einige Wochen mit mehren Leuten Arbeit ist. Zudem wir da leute bräuchten die sich verdammt gut mit network foo auskennen müssen.
Neoraider hatt die issues dazu nict umsonst in ein eigenen milestone gepackt :D https://github.com/freifunk-gluon/gluon/issues?q=is%3Aopen+is%3Aissue+milest...
Die zweite Möglichkeit wäre VXLAN das ist relativ neu und es existiert noch so gut wie garkeine doku dazu Dazu könnte man ein LEDE-Paket bauen, das VXLAN-Support in netifd einbaut, z.b. als Script in /lib/netifd/proto
die zweite Variante hätte wahrscheinlich eh zu folge das die network conf umfangreicher angepackt werden muss.
Aktuell arbeite ich gerade an der abstraktion der geoposition der router. Dazu wird der config mode wohl so angepasst, das es ein flag share location geben wird und ein dropdown menü wo man folgendes auswählen kann:
autolocation staticlocation auto & staticlocation (no location)
Beim letzten Punkt bin ich mir noch nicht sicher evtl. würde ich da einen Text hinsetzen das diese Option signifikante Nachteile auf die lokale Netzqualität haben kann.
cheers Tarek
Aktuell arbeite ich gerade an der abstraktion der geoposition der router. Dazu wird der config mode wohl so angepasst, das es ein flag share location geben wird und ein dropdown menü wo man folgendes auswählen kann:
autolocation staticlocation auto & staticlocation (no location)
Beim letzten Punkt bin ich mir noch nicht sicher evtl. würde ich da einen Text hinsetzen das diese Option signifikante Nachteile auf die lokale Netzqualität haben kann.
Da hatte ich mich ja auch schonmal rangesetzt, dann aber irgendwann in die ecke geschmissen, weil die luci-oberfläche imho von gluon ziemlich vergewaltigt wurde. Luci bringt von Haus aus wirklich tolle Funktionen mit, mit denen man Formularfelder wirklicher hervorragend verwalten kann. Man kann jedes Feld mit einem sehr flexiblen Verifier bestücken [0] und die ganze Abschnitte der Oberfläche DIREKT auf eine UCI-config mappen [1]. Konfigurationsseiten werden damit wirklich zu Zweizeilern, man muss eigentlich nur noch Labels für die Formularfelder schreiben und der Rest ist dann schon automatisiert. Leider war die Modularisierung der Luci-Oberfläche in gluon, als ich mir das angesehen habe, dafür alles andere als geeignet und statt dieser schönen Lösung hatten einige Module etwa drölf Verify-Methoden und x uci.set()-, uci.commit()- usw. Aufrufe, also ziemliches Gefrickel...
Viele Grüße, Eike
[0] http://luci.subsignal.org/trac/wiki/Documentation/Datatypes [1] https://github.com/openwrt/luci/wiki/CBI