Dev June 2017

dev@lists.ffnw.de

10 participants
12 discussions

by Jan-Tarek Butt

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

6 years, 6 months

Offline-SSID

by Simon Kurka

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

7 years, 1 month

Sign Request 20170629

by Johannes Rudolph

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

7 years, 4 months

Vorschlag für nightly autoupdater branche

by Jan-Tarek Butt

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

7 years, 5 months

Neue Hoods

by Johannes Rudolph

Hallo zusammen, ich würde gerne zeitnah eine neue Firmware bauen. Diese soll unteranderem noch den Fehler beheben, dass das eigene Netzwerk aktuell beim scan Mode des Hoodselectors nicht herausgefiltert wird. Zum anderen haben Stefan und ich einen weiteren Netzsplit vorbereitet. Dafür haben wir die 4 größten Hoods geteilt. Diese sind aktuell: Leer Oldeburg Osnabrück Butjadingen Server seitig hat Stefan alles dafür schon vorbereitet. Ich habe auch schon ein Hoodfile vorbereitet: https://git.ffnw.de/snippets/19 Dort habe ich zum einem die 4 großen Hoods geteilt und zum anderen habe ich versucht durch geschicktes verschieben die Anzahl der Rechtecke zu reduzieren, um das Hoodfile möglichst klein zu halten. Ich habe für die bessere Planbarkeit den Hoodgen um neue Funktionen erweitert. (https://hoodgen.ffnw.de) 1. Beim Klicken auf "Load Nodes" im oberen Menü werden alle aktuellen Nodes geladen und auf der Karte mit dargestellt, dieses hilft sehr gut beim ziehen von Hoodgrenzen in dichbesitelten Freifunk gebieten (Oldenburg, Osnabrück) 2. Wenn man die Nodes in den Hoodgen gelanden hat und auf "Export to JSON drückt", wird zum einem wie gewohnt der JSON Export erstellt, zum anderen werden nun die Nodes in der Jeweiligen Hood gezählt. Damit hat man beim Erstellen und verschieben von Hoods ein besseres Gefühl, wie viele Nodes in der jeweiligen Hood landen werden. Insbesondere bitte ich die Oldenburger das Hoodfile sich anzuschauen, was die Trennung von Oldenburg angeht. Wenn keiner was dazu sagt, würde ich das sonst deuten, dass alle mit meinem Vorschlag einverstanden sind. Gruß Johannes

7 years, 5 months

Fwd: [gluon] [SITE] Site seeds and VXLANs

by Jan-Tarek Butt

-------- Forwarded Message -------- Subject: [gluon] [SITE] Site seeds and VXLANs Date: Tue, 27 Jun 2017 23:41:46 +0200 From: Matthias Schiffer <mschiffer(a)universe-factory.net> To: gluon(a)luebeck.freifunk.net <gluon(a)luebeck.freifunk.net> Hi, I've just pushed a bunch of commits adding support for wired meshing over VXLANs. What does this mean? - Newly setup Gluon nodes will encapsulate wired mesh traffic (Mesh-on-LAN/WAN) in UDP packets using the VXLAN protocol. Instead of the batman-adv ethertype, the packets will be normal IPv6 UDP on port 4789 using link-local adresses for unicast, and the address ff02::15c for multicast - Nodes upgraded from Gluon v2017.1 or older will continue to use the "legacy" wired meshing without VLXANs for now. - Gluon v2017.2 will support both VXLANs and the legacy protocol. The setting can be changed in the Advanced Settings of the Config Mode, or by setting the "legacy" attribute of the mesh_wan and mesh_lan UCI sections. Both sides of a wired mesh connection must be set to the same protocol for the link to work. - Gluon v2017.2 + 1 will drop legacy support, settings will be upgraded to use VXLANs automatically - Each mesh domain / site will use a unique VXLAN ID, ensuring that accidental wired mesh connections between different sites won't bridge the meshes (especially important in sites that automatically assign nodes to mesh domains using tools like the Hood Selector) To assign a unique VXLAN ID to a site, a new setting must be added to site.conf: the site seed. The site seed simply consists of 32 bytes of random data in hexadecimal representation. Please refer to the documentation and the included example at [1] for the recommended way to generate a site seed. -- NeoRaider [1] http://gluon.readthedocs.io/en/latest/user/site.html

7 years, 5 months

Puppet Repo Änderungen

by Stefan

Hallo zusammen, ich muss grad mal ein wenig Dampf hier ablassen. Simon und ich haben in den letzen 2 Wochen wirklich viel Arbeit ins Puppet sowie unser AS gesteckt. Heute Morgen habe ich mich gewundert, warum beim FFNW Modul Puppet stockte. Nachdem ich mir den Source von https://git.ffnw.de/ffnw-puppet/puppet-ffnw/commit/088409c72e8b75dfb699ea0c… angesehen habe, war es klar. Im Quellcode werden globale Variable genutzt (z.B $::{nat_ip}) die aber gar nicht global sind, sondern nur vom FFNW Modul gesetzt werden. Meine Große Bitte wäre es hier, jede Änderung über Merge Requests zu löschen und das auch nur, wenn man weis was man tut. Das ist doppelte Arbeit die wir uns hier grade wieder machen. Danke. Stefan

7 years, 5 months

Firmware md5sum Checksumme

by Christian 'picard' Lorenz

Moin, kann sich mal jemand die Checksumme Dateien anschauen. Zumindest in der unten gezeigten md5 ist der Pfad zu viel. pic@pic_lapi:~/Downloads$ md5sum -c gluon-ffnw-20170530-tp-link-tl-wr841n-nd-v11.bin.md5 md5sum: /var/www/dev/firmware/20170530/gluon-ffnw-20170530-tp-link-tl-wr841n-nd-v11.bin: Datei oder Verzeichnis nicht gefunden /var/www/dev/firmware/20170530/gluon-ffnw-20170530-tp-link-tl-wr841n-nd-v11.bin: FAILED open or read md5sum: WARNUNG: die aufgeführte Datei konnte nicht gelesen werden pic@pic_lapi:~/Downloads$ vi gluon-ffnw-20170530-tp-link-tl-wr841n-nd-v11.bin.md5 (entfernt /var/www/dev/firmware/20170530/) pic@pic_lapi:~/Downloads$ md5sum -c gluon-ffnw-20170530-tp-link-tl-wr841n-nd-v11.bin.md5 gluon-ffnw-20170530-tp-link-tl-wr841n-nd-v11.bin: OK Danke pic -- Freifunk Gruß Freifunk steht für freie Kommunikation in digitalen Datennetzen! Wir verstehen frei als öffentlich zugänglich, im Besitz der Gemeinschaft & unzensiert.

7 years, 6 months

Hoodselector ignoriert eigen mesh-bssid nicht -> router bleibt in default hood

by lrnzo

Hallöle, folgendes Konstruk: offloader + MoW-Router, keine anderen ff-router in Funkreichweite. Offloader findet vermutlich aufgrund von Koordinaten in die richtige Hood (Badiburg). Der Router sieht aber beim wlan-scan immer auch seine eigene bssid (default) und bleibt dann stumpf darin hängen. Abhilfe schuf: bssid per uci händisch setzen und hoodselector laufen lassen. LG lrnzo

7 years, 6 months

Fwd: [WLANware] [gluon] [ANNOUNCE] Gluon v2016.2.6 and v2017.1

by Bjoern Franke

FYI -------- Weitergeleitete Nachricht -------- Betreff: [WLANware] [gluon] [ANNOUNCE] Gluon v2016.2.6 and v2017.1 Datum: Sat, 10 Jun 2017 14:50:46 +0200 Von: Matthias Schiffer <mschiffer(a)universe-factory.net> Antwort an: Deutschlandweite Liste für WLAN Themen Layer 1-7 <wlanware(a)freifunk.net> An: gluon(a)luebeck.freifunk.net Kopie (CC): Freifunk Firmware Entwicklung <firmware-devel(a)freifunk.net>, WLANware <wlanware(a)freifunk.net>

7 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Dev June 2017