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
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
Hi,
> ich habe ma einen neuen branch gemacht für das nächste update:
>
> https://git.ffnw.de/ffnw-firmware/siteconf/commit/88dd11323ba571dd30688724a… <https://git.ffnw.de/ffnw-firmware/siteconf/commit/88dd11323ba571dd30688724a…>
>
> dort habe ich den Ordner für den stable link mal angepasst.
>
> Alle Router schauen jetzt in das Verzeichnis
>
> autoupdate.ffnw/stable
>
> das könnten wir so lassen
Ich lösche das noch mal. Wir sollten das erstmal besprechen
befor wir da potentiell unnötie branchs und co aufmachen.
> nach dem nächsten update mit gluon 2016.2.6 ändern wir den zukünftigen stable und testing Ordner auf:
>
> autoupdate.ffnw/stablelede2017
> autoupdate.ffnw/testinglede2017
>
> der Branch wäre dann immer noch „stable“ bzw „testing“
>
> das erste update mit Gluon 2017.x.x kommt dann in den Ordner „stablelede2017“
>
> alle alten router die dann noch mal online kommen würden dann mit dem autoupdater erst unsere letzte Gluon 2016.2.6 Firmware laden und installieren und danach auf lede wechseln.
>
> Irgendwann können wir dann wieder aus stablelede2017 wieder stable machen
>
> Was haltet ihr von dem Vorschlag?
Wir könnten es wahrscheinlich einfacher machen.
Wir lassen
autoupdate.ffnw/stable auf den 201707** (v2016.2.x) Ordner zeigen.
ab der Version 201707** (v2016.2.x) zeigt die autoupdater url z.b. auf
autoupdate<anhängsel>.ffnw/stable
vg
Tarek
Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
LG lrnzo
Hi,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
* Firmware-Version: 20170629
* Gluon-Version: 2016.2.6
* Download: https://firmware.ffnw.de/20170629
Folgende Änderungen gab es:
* siteconf Repo:
* für x86 add kmod-usb-net-mcs7830
* drop libwlocate
* drop lwtrace
* packages Repo:
* Hoods:
* Osnabrueck -> Osnabrueck1 und Osnabrueck2
* Oldenburg -> Oldenburg1 und Oldenburg2
* Leer Emden Aurich -> Leer und Aurich
* Butjadingen -> Butjadingen und Tossens
* Hoodselector:
* fix filter own Network
* fix filter default Hood
Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem Befehl eingesehen werden:
https://git.ffnw.de/ffnw-firmware/siteconf/compare/20170530...201706
Die Änderungen an unseren eigenen Paketen können im Packages-Repository mittels folgendem Befehl eingesehen werden:
https://git.ffnw.de/ffnw-firmware/packages/compare/201705...201706
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://wiki.nordwest.freifunk.net/Entwicklung/Firmware_releaseprozess#Firm…
Viele Grüße
Johannes
Hallo Leute,
mittlerweile ist ja in der firmware
fastd.mesh_vpn.method='null' 'salsa2012+umac'
gesetzt und alle supernodes können die Methoden
method "salsa2012+umac";
method "null+salsa2012+umac";
method "null";
soweitsogut. Aber effektiv bauen alle uplinks ihren fastd-tunnel immer über die (langsamere) Methode salsa2012+umac auf. Es sei denn man schmeißt diese Methode routerseitig zB per uci raus. Letzteres habe ich jetzt updatefest auf vielen routern getan:
uci del_list fastd.mesh_vpn.method='salsa2012+umac';uci del_list fastd.mesh_vpn.method='null';uci add_list fastd.mesh_vpn.method='null';uci commit fastd; echo '/etc/config/fastd' >> /etc/sysupgrade.conf;/etc/init.d/fastd restart
aber was sollen Leute machen, die "nur" den configmodus nutzen? Habe mich gefragt, ob man nicht in den wizzard bei der vpn-config ein Menü tun könnte so nach der Motto "schnelles oder extra-verschlüsseltes vpn". Also solange wir noch kein l2tp haben.
LG Lorenz
Hi zusammen,
Clemens hatte vor einiger Zeit mal den nigthly autoupdater
branche im siteconf repo angelegt.
Ich habe gestern testweise mal den nigthly CI in das packages repo eingebaut.
Langfristig würde ich mir wünschen den nigthly CI in dem packages repo zu lassen.
Das ermöglicht bsp. das Änderungen die in den Master gemerged wurde automatisch
Auf die Router installiert werden die auf dem nigthly branch zeigen.
Somit können Entwickler relativ einfach neue Änderungen von anderen Entwicklern
testen und auf bestehenden Änderungen entwickeln.
Ein nigthly branche im siteconf repo ist nicht wirklich hilfreich.
Da dieses relativ selten, meist zur Zeit eines releases geädert wird.
vg
Tarek
Hallo zusammen,
gibt es die Möglichkeit, mittels eines Befehles die MAC Adresse und die
Seriennummer des Routers anzeigen zu lassen? Habe noch eine alte Rechnung
eines Routers gefunden und nun würde es mich mal interessieren, wo dieser
eigentlich nochmal gelandet war.
Freundliche Grüße
Klaus Dint
