Hi zusammen,
Ich wollte meine Ideen und Pläne gerne mal vorstellen und
gemeinsam mit euren eine Roadmap erarbeiten. :)
Meine Pläne für das Netz und die Firmware:
1. Hoodselector fertigstellen: Aktuell fehlen noch ein paar
Zustände die in den kommenden Wochen angeschlossen sein sollten.
Das betrifft hauptsächlich den BATAMAN_GATEWAY mode. Z.B. das
verhalten beim zurück wechseln in die Eigene hood wenn sich ein
mesh Router an eine benachbarte hood gehängt hat. Siehe dazu:
https://github.com/freifunk-gluon/gluon/pull/997
2. Support für L2TP VPN.
Aus dem gluon upstream soll l2tp in unsere Firmware backported werden.
Das ist dank der neuen Patch Möglichkeit in unserer Firmware nun relativ
einfach realisierbar.
3. Router als Batman-adv Gateways
Die Idee hatte ich schon länger im Kopf bin aber bisher noch nicht wirklich
dazu gekommen in der Richtung was zu machen. Im Grunde ist die Idee das,
leistungsfähigere Router bsp. Archer C7 einen eigenen VPN zu exit Servern
aufbauen wie z.B. IPredator, HidemyAss, Tor, usw. Paralell zu den VPN soll
ein weiterer VPN fastd oder l2tp die virtuelle mesh Verbindung für das interne
Netz weiter zur Verfügung stellen.
Vorteile bei dieser Struktur:
* Es gibt deutlich mehr Exit Nodes.
* Es kommt dem Dezentralen Konzept ein Stück näher.
* Unser Server backbone wird entlastet (bessere lasten Verteilung).
* Evtl. Technische Lösung der VDS
Nachteile:
* IPv4 würde in dem Konstrukt wahrscheinlich Probleme machen.
Lösung könnte hier ddhcpd sein ein zurzeit experimenteller distributed dhcp
Server.
4. Prof of concept erstellen für generische Layer3 Routern zwischen hoods.
Hierzu habe ich mir noch keine näheren Gedanken gemacht. Aber der Titel
sollte schon aussagen worum es geht.
Das sind bisher nur Ideen und Vorstellungen woraus letztlich eine Roadmap
entstehen kann.
Ich würde mich über feadback und/oder andere Ideen Freuen :)
Schöne Grüße
Tarek
Moin Moin leute,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
* Firmware-Version: 20170822
* Gluon-Version: v2016.2.x
* Commit ID: d722c2638a9f7a662ea46b74e997a3e460e70971
* Download: https://firmware.ffnw.de/20170822
Folgende Gluon spezifischen Änderungen gab es unter anderen:
* Backport sysupgrade error handling fixes
* prereq: backport changes to git detection to work with newer Git versions
* automake: import upstream fix for perl 5.26
Die upstream Änderungen findet ihr hier:
https://github.com/freifunk-gluon/gluon/compare/0d2b078...d722c2
Folgende Comunnity spezifischen Änderungen gab es:
package repo:
* Neues Paket "disable-11s" welches das versehentliche einschalten von IEEE802.11s
wieder rückgängig macht.
* Hoodselector bug: nicht abgefangener Null Index zugriff behoben danke an Lorenz
https://lists.ffnw.de//pipermail/dev/2017-August/002213.html
Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20170629..…
siteconf repo:
* Autoupdater url für wechsel auf Gluon v2017.1.x angepasst.
Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20170629..…
Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu
signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter:
https://mediawiki.ffnw.de/Firmware/Releaseprozess#Firmware_signieren
Schöne Grüße
Tarek
Hallo zusammen,
auf dem letzten Treffen kam nochmals die Frage nach einer Offline-SSID
auf. Tarek möchte so eine grundlegende Entscheidung auf der ML diskutieren.
Ich denke wir sollten eine Offline-SSID einführen. Diese muss nicht
direkt vom Online-Status des Routers herrühren, sondern könnte auch
durch ein fehlendes (Batman-)Gateway ausgelöst werden.
Grund: Ohne Gateway Anbindung hat man nicht den erwarteten Zustand.
Befindet man sich beispielsweise in Oldenburg und verbindet sich mit
unserem Netz, erwartet man eine IPv4 und eine Publicv6 aus dem
Oldenburger Bereich zugewiesen zu bekommen und mit jedem anderen im
Freifunk Nordwest Netz und auch mit dem gesamten Internet Daten tauschen
zu können.
Für Nutzer, die auch die ganz grundlegenden lokalen Features nutzen,
sollte es kein Problem sein sowohl Offline- als auch Online-SSID zu
speichern / sich damit zu verbinden.
Wenn wir das nicht tun provozieren wir an reinen Mesh-Routern ohne
Anbindung ein Offline-legen der User. Die Geräte verbinden sich mit
Freifunk, schalten mobile Daten ab und sind offline.
Außerdem kann es auch beim Ausbau unterstützen: Mein Blick in der
Oldenburger Innenstadt geht gerade dahin, wo ich einen Uplink her
bekomme, obwohl ein weiterer Routerstandort auch ohne cool ist. Ich
werde aber keine Router aufbauen, die von vornherein offline sind und
Nutzer beeinträchtigen. Mit Offline-SSID kein Problem und die Geräte
würden sich auf die normale SSID konfigurieren, sobald ein Uplink-Router
in der Nähe ist.
--
Viele Grüße,
Simon
Hi zusammen,
Die Portierungen zu gluon v2017.1.x sind nun weitestgehend abgeschlossen.
Es müssen nur noch ein paar Schönheits Änderungen erledigt werden, dann
ist soweit alles abgeschlossen.
vg
Tarek
Hallo Leute
dass man bei LEDE jetzt im config-modus wählen kann zwischen vpn mit und ohne crypto ist schön, aber leider wirkungslos. ich habe den default "hohe Geschwindigkeit" beibehalten, meine /etc/config/fastd beinhaltet folgendes:
config fastd 'mesh_vpn'
list method 'null'
list method 'null+salsa2012+umac'
list method 'salsa2012+umac'
und im logread steht: daemon.info fastd[4121]: new session with <mesh_vpn_backbone_peer__10000> established using method `salsa2012+umac'.
mir fallen spontan zwei mögliche Lösungen ein:
1. die anderen optionen 'null+salsa2012+umac' und 'salsa2012+umac' müssen ganz rausfliegen, wenn per config-modus "hohe Geschwingkeit gewählt wird"
2. vielleicht müssen Gateway-seitig die Optionen auch so sortiert werden, dass dort 'null' zuoberst steht. Aber das wäre nur ein Schuss ins Blaue. Kennt sich jemand aus?
LG Lorenz
Hi zusammen,
ich habe einen Merge request den ich nicht testen
kann da mir dazu die nötige Hardware fehlt :(
Es geht um Folgenden:
https://git.ffnw.de/ffnw-firmware/packages/merge_requests/65
Das test Setup dazu müsste folgender maßen aussehen.
Einen VPN Router in hood X.
Einen mesh Router der in hood Y ist aber sich zur hood X verbunden
hat weil es keinen VPN Router aus hood Y findet.
Wenn das soweit steht sollte folgende Ausgabe kommen.
root@v2017testing:~# hoodselector
No VPN connection found
Batman gateways found
Position found.
Geo hood and bssid hood are not equal, do wifi scan...
Set hood "X"
Hood set by batmanHasGateway mode, GW source is wifi
Das heißt der mesh Router hat festgestellt das es eigentlich gar nicht
seine hood ist schaut einfach mal nach ob einer aus seiner hood in der
nähe ist. In dem o.g. Fall ist kein Router aus hood Y da.
Nachdem du diese Ausgabe gesehen hast Stöpsels du den anderen VPN Router
aus hood Y ein.
Danach sollte der mesh Router automatisch zurück wechseln.
Freiwillige vor ;P
vg
Tarek
Hi zusammen,
Ich würde mit dem Update auf v2017.X auch gerne die Umstellung von IBSS auf 11s Only machen wollen.
Der Support für IBSS fliegt bald bei Gluon raus.
Die ursprüngliche Idee war es, ein neues Packet zu bauen welches eine Abwärtskompatibilität gewährleistet.
Das ist aber relativ aufwendig zu entwickeln daher daher habe ich folgenden Vorschlagt:
Mit der Firmware zum wechsel auf v2017.X kommt ein neues Package welchen nach an einem bestimmten Datum X
das IBSS Netz abschaltet und das 11s ein. Das sollte denke ich ein sehr einfacher weg sein den wechsel zu
vollziehen. Ich würde ungern beide Netze Parallel laufen lassen da die Vergangenheit gezeigt hat das dies
zu Problemen führen kann.
Wenn alle mit der Idee soweit einverstanden sind würde ich vorschlagen das Datum X auf 2 Wochen nach Release
zu setzen?
Damit würde das IBSS 2 Wochen nach der Freigabe der neuen Firmware abgeschaltet sein.
Schöne Grüße
Tarek
Hallo Leute,
ich habe dem Hoodselector beigebracht, (auch nichtkonvexe) Polygone als Hoods zu erkennen. Hierzu habe ich die Strahl-Methode nach dem Punkt-in-Polygon-Test nach Jordan [1] in lua implementiert und als Funktion in den hoodselector eingebaut. Hierzu habe ich einen lokalen branch polygone-hoods vom packages-repo erstellt und würde den ganz gerne mit
git push --set-upstream origin polygone-hoods
pushen. Aber:
GitLab: You are not allowed to push code to this project.
;(
kann mich jemand als Developer hinzufügen?
Auch die hoods.json habe ich entsprechend angepasst. Jede n-eckige Hood besteht jetzt aus einer Box, mit n+1 Punkten, wobei Punkt[1]=Punkt[n+1]. Unter [2] kann man sich das Ergebnis anschauen. Natürlich sind damit jetzt auch schräge Hoodgrenzen möglich, zB entlang Teutoburger Wald oder Autobahnen etc. Es muss nur jemand (tm) machen.
Habe die neue Kombination aus hoodselector + hoods.json mal durch mein test-script [3] laufen lassen. er hat alle hoods erkannt und kam auch überall online :)
Übrigens: Verschachtelte Hoods (also zB. Bad-Iburg innerhalb landkreis-osnabrück) stellten übrigens schon früher kein Problem dar, sofern sie in der hoods.json richtig sortiert waren. Wenn die "Unterhood" vor der "Oberhood" steht, kam der hoodselector immer schon damit klar.
[1] https://de.wikipedia.org/wiki/Punkt-in-Polygon-Test_nach_Jordan
[2] http://bl.ocks.org/d/ea7ee9d9ff49ff90047ebda82e306c77
[3] https://git.nordwest.freifunk.net/lrnzo/check-hoods
LG lrnzo
Hallo zusammen,
ich scheine einfach zu blöd zu sein. Ich versuche meine Unifi AC Pro mit der Freifunksoftware zu flashen und ich bekomme das nicht hin:
1. Versuch mit dem Controller
2. mit Pumpkin
3. mit dem Terminal von Mac
4. Versuch mit dem Controller
wie bringt man diesem Teil bei, die Software anzunehmen. mit dem Controller sehen ich immer die Version 3.8.6.6650
Grüße
Karsten
Hallo zusammen,
bei Unifi AP AC Pro gibt es einen zweiten Lan-Port. Wird aus dem Port das Freifunk-Lan ausgegeben?
Ich Netz habe ich dazu nichts gefunden.
Grüße Karsten
