Firmware 20171220 Weihnachts Release

How How How, 

dieses Release ist ein besonderes Firmware-Release und ein Geschenk an unsere tolle Community. Es bringt die finale Version des hoodselectors, welcher nun seinen letzten Zustand lernt. Desweiteren werden einige Bugfixes und Optimierungen im hoodselector enthalten sein. Somit ist ein großer Milestone in unserer Entwicklung zum dezentralen Netz abgeschlossen.

(mehr …)

Bericht aus dem Maschinenraum – Projekt AS206313

Moin Moin,
das Jahr neigt sich dem Ende. Wir möchten die besinnliche Zeit nutzen euch erneut einen Bericht aus dem Maschinenraum zu präsentieren. Mit dieser Artikelserie versuchen wir in unregelmäßigen Abständen über die Fortschritte unserer Arbeit zu informieren. Insbesonders über die Projekte welche naturgemäß langatmiger sind und eine gewisse Zeit benötigen um vernünftig zu reifen.
In dieser Ausgabe präsentieren wir euch den aktuellen Stand unseres Projektes AS206313. (mehr …)

Großes Release 20171211 auf LEDE

Moin Moin Leute,

 

Es ist wieder soweit wir haben eine neue Firmware gebaut. Diesmal handelt es sich um ein großes Rundum-Update.
Für dieses Update gibt es allerdings ein paar Dinge zu beachten. Falls ihr zu irgendwelche Punkten fragen habt: Mail an die Info Adresse.

 

Erster wichtiger Hinweis

Ältere Firmware Versionen sollten vorher auf Version 20170822 [11]  upgraden, um möglichen Problemen vorzubeugen. Router, die den autoupdater an haben, sollten also bereits auf 20170822 sein und updaten somit auch automatisch auf die Version 20171211. Insbesondere gibt es ein Problem in allen Gluonversionen vor 2016.2.7, welches die x86 Systeme betrifft. Diese verlieren ihre Konfiguration, wenn sie auf Gluon 2017.1.x updaten. Ältere Firmwareversionen sollten vorher auf 20170822 [11] upgraden, bevor diese 20171211 installieren. Wer den autoupdater deaktiviert hat, kann mit folgendem Befehl automatich updaten.
autoupdater -f
Der autoupdater sorgt dafür, dass alle Router zunächst mal auf  Version 20170822 (Gluon 2016.2.7) und erst von dort dann weiter auf die 20171211 (Gluon 2017.1.4). Auch wenn später noch Router mit noch älteren Versionen aus dem Schrank geholt werden, updaten die zuerst einmal auf die 20170822.

 

Zweiter wichtiger Hinweis

Für alle, die Setups mit PoE-Passthrough betreiben. Wenn ihr auf Nummer sicher gehen wollt, dass alle eure PoE-Passthrough Geräte das Ausrollen der Firmware heile überstehen, solltet ihr dort, wo PoE-Passthrough aktiviert ist, sicherstellen, dass _nicht_ genau dann vorne in der PoE-Kaskade ein reboot stattfindet, wenn weiter hinten geflasht wird. Mit anderen Worten es sollte genug Zeit nach dem Update der hinteren Router vergangen sein, bevor die vorderen updaten. Die eleganteste Möglichkeit hierzu ist wohl, die Minuten der cronjobs auf den einzelnen Routern entsprechend anzupassen. Hierzu mit vi in der /usr/lib/micron.d/autoupdater die erste Spalte bearbeiten. Danach noch /etc/init.d/micrond reload ausführen. Diese variante ist allerdings nicht update fest und ist somit beim nächsten update nicht mehr exsistent!

 

Alternativ kann man den Autoupdater deaktivieren und das Update zu einem Zeitpunkt händisch ausführen, wenn sicher ist, dass die per PoE-Passthrough betriebenen Geräten das Update bereits installiert haben. Folgender Befehl tut das:

 

Um zu prüfen das PoE-Passthrough aktiv ist. Wenn der zurück gelieferte wert 1 ist, ist es aktiv.

uci get system.gpio_switch_poe_passthrough.value
Dann könnt ihr mit folgendem Befehl den autoupdater ausschalten.

uci set autoupdater.settings.enabled='0'
uci commit autoupdater
Ob und welcher Aufwand sich lohnt muss jede/r selbst entscheiden. Das bricken eines Routers kann mit einer gewissen Warscheinlichkeit passieren, muss aber nicht.

 

Dritter wichtiger Hinweis

Ein potentielles Problem betrifft die meisten Virtuellen Maschinen. Die Gluon 2017.1.x images sind größer als die 2016.2.x images. Dies betrifft die x86 Architektur. Wenn deine Festplatte auf 2016.2.x images basiert, muss diese auf 273MB order größer vergrößert werden. Dies solltest du vor den update auf 20171211 machen! Der Befehl für qemu wäre z.b. folgender:

qemu-img resize $IMAGE 273MB

(mehr …)

geolocator (Software defined GPS)

Hallo zusammen,

Mein Name ist Jan-Tarek Butt. Ich studiere in meinem 4. Semester Informatik an der Hochschule Emden/Leer in Niedersachsen. Einige von euch kennen mich wahrscheinlich schon als langjähriges aktives Mitglied der Freifunk Community und vom letzten Google Summer of Code 2016. Dieses Jahr bin ich wieder einer der Studenten die für Freifunk am Google Summer of Code 2017 teilnehmen dürfen. Im folgenden Beitrag möchte ich eine kleine Einführung in mein diesjährigen Projekt beim Google Summer of Code geben. Wie letztes Jahr habe ich auch dieses Projekt in 3 Teilprojekte zerlegt: web backend, gps-share und LEDE Package (mehr …)

Bericht aus dem Maschinenraum (Teil 2): Umzug von Hoods

Bereits seit mehreren Wochen planen wir den Umzug von 2 Hoods: Die Friesland / Wilhelmshaven Hood soll auf einen leistungsstärkeren Server umgezogen werden. Zusätzlich soll unser altes Defaultnetz auch auf unsere neue Infrastruktur eingerichtet werden. Diese beiden Milestones haben uns in den letzten Wochen einiges an Arbeit bereitet:

Wie plant man so einen Umzug sinnvoll und auf welche Punkte im Hintergrund muss dabei geachtet werden? Fangen wir mal ganz von vorne an.

Womit werden die Hoods eigentlich eingerichtet?

Unser aktuelles Hood-Setup läuft auf Basis von Puppet. Puppet ist ein Systemkonfigurationswerkzeug. Hauptanwendungsfall ist die automatisierte Konfiguration mehrerer Computer via Netzwerk. Konfigurationsparameter können etwa die Installation von Software, Datensynchronisation oder das Ausführen von Programmen sein.

Puppet ist Open Source und prinzipiell plattformübergreifend-unterstützt werden jedoch insbesondere unixoide Betriebssysteme wie Unix, Linux und FreeBSD. Jeder einzelner unserer Server ist über eine Konfigurationsdatei eingerichtet worden – in der alle Details für die automatische Installation eingetragen werden.

In der oben angegebenen Konfiguration werden mehrere Teile der Hood definiert. Wir unterscheiden bei unseren IPv6 Netzen zwischen 2 Typen:

  • 2a03:2260:1001:9000::/64 ist ein Netz, aus dem die Router und Clients Ihre IP Adressen beziehen
  • 2a03:2260:1001:0104::/64 ist ein internes Netz, das ausschließlich für unser dynamisches OSPF Routing (sprich das Routing zwischen unseren Hoods) genutzt wird.

Standardmäßig werden alle Konfigurationseinstellungen für den Server im Bereich network::inet gesetzt, damit der Server normal an das Internet angebunden ist.

Wie läuft so ein Umzug genau ab?

Für den Umzug unserer Hoods haben wir uns einen extra Milestone in unserem Gitlab erstellt, in dem entsprechende Issues nach deren Prioritäten abgearbeitet werden müssen. Dabei entsteht der große Vorteil, dass keine wichtigen Arbeiten (die in Vergessenheit geraten könnten) übersehen werden. Die einzelnen Issues können einem Administrator oder Entwickler hier direkt zugeordnet werden. Wenn hier alle Issues geschlossen und umgesetzt wurden, können die entsprechenden Hoods umgezogen werden. Zum Teil ist hier die Mitarbeit aus unterschiedlichen Teams notwendig.

Bereits vor einigen Monaten haben wir eine Hood (Kreis Steinfurt, wir haben hier bereits drüber berichtet) umgezogen. Aus den hier gemachten Fehlern haben wir gelernt und auch vernünftige Workflows für solche Umzüge gestrickt.

Der eigentliche Umzug der Hoods besteht darin, dass die Router (die immer noch mit dem alten System ihren VPN Tunnel aufrecht erhalten) zu dem neuen Server wechseln. Hierbei wird im ersten Schritt die TTL der DNS Einträge auf einen kleinen Wert gesetzt. Die TTL ist dafür zuständig, dass der Client sich den DNS Eintrag für eine bestimmte Zeit merkt. Wir benötigen hier eine relativ kleine Zeit, damit die Router nach Abschalten der alten Einträge eine neue Anfrage starten. Wir können hier unter anderem genau beobachten, wieviele Router sich schon auf den neuen Server verbunden haben.

Nachdem die DNS Einträge geändert wurden, müssen wir die VPN Verbindung bewusst von unserer Seite trennen, sodass der alte Server keine Tunnel mehr annimmt und alle Router eine neue Verbindung zu der neuen Hood aufbauen. Hierfür stoppen wir den kompletten fastD Dienst auf den alten Servern und warten gespannt einige Minuten.
Wenn alle Router den neuen Server gefunden haben, kann das alte System komplett abgeschaltet werden: Wir machen es uns hier aber auch nicht so einfach, denn den alten Server nutzen wir weiterhin als Exit – der Exit leitet den Traffic, der im Freifunk Nordwest Netz entsteht weiterhin zum Freifunk Rheinland.

Eins ist klar: Routine wird bei unserem Netz nie eintreten, es warten immer spannende und neue Baustellen…

Bevor wir es noch vergessen: Die Umzüge haben reibungslos geklappt und sollen ein kleines Weihnachtsgeschenk für alle Nutzer sein 🙂

 

Bericht aus dem Maschinenraum (Teil 1): map.ffnw.de

Auf unseren Treffen haben wir schon häufiger darüber diskutiert, dass es für Außenstehende manchmal nicht so leicht ersichtlich ist, was wir als Freifunk Nordwest – außer dem Bewerben und Aufstellen von Routern überhaupt so machen. Um das zu ändern, wollen wir zukünftig in regelmäßigen Abständen Einblicke in unsere Arbeit an der Technik geben und vorstellen, welche Neuerungen wir planen und umsetzen und welche Problemlösungen wir entwickeln.

Den Start dieser Reihe mache heute ich und stelle euch ein kleineres Projekt vor, an welchem ich in den letzten Wochen einige Zeit gearbeitet habe. Zu tun hat dies mit unserer Freifunk-Karte unter map.ffnw.de.

Dem Einen oder Anderen wird aufgefallen sein, dass unserer Freifunk-Karte in letzter Zeit doch etwas langsam gewesen ist. Weil auch mir irgendwann sauer aufstieß, dass mein Laptop etwa 8 und mein Smartphone sogar fast 20 Sekunden benötigte um die Seite zu laden, hatte ich mir vorgenommen, mich während unseres Freifunk-Hackathons der Sache anzunehmen und die Performance nach Möglichkeit zu verbessern.

Gesagt getan und ich fing an, die Performance-Probleme einzugrenzen. Dabei fielen mir im wesentlichen zwei Dinge auf:

  • Das Javascript, welches die Map darstellt, verbrauchte ziemlich viel Rechenleistung – Mein CPU-Lüfter heulte bei jedem Aufruf hörbar auf
  • Die Datenmenge, die das Javascript lud, war durch unsere in den letzten Jahren stark gewachsene Routerzahl wirklich immens geworden und lag bei etwa 2 Megabyte (!). Viel zu viel für eine doch recht einfache Anwendung; für mobilen Aufruf sowieso.

Einige Stunden lang versuchte ich nun zunächst das Javascript zu optimieren, indem ich nach und nach einzelne Funktionen, die ich des Leistungshungers verdächtigte, abschaltete. Ohne Erfolg. Mit einem kurzen Prototypen versuchte ich dann zu testen, ob vielleicht einfach nur die verwendete Bibliothek für die Kartendarstellung, leaflet, an seine Leistungsgrenzen geraten war. Aber die Darstellung mehrere hundert Punkte und Linien auf einer Karte packte leaflet dann doch völlig problemlos. Mit weiteren Experimenten wuchs die Erkenntnis, dass vielleicht der Zeitpunkt gekommen sein könnte, mit der Entwicklung einer leistungsfähigeren Anzeige zu beginnen.

Dieser Neuentwicklung sollte beim „Fundament“ beginnen, also bei der effizienten Übermittlung der Kartendaten an das Javascript. Der aktuelle Mechanismus funktioniert etwa so:

In jeder unserer Hoods (Subnetze) läuft auf einem Supernode ein sog. Hopglass-Server, der die Daten der Freifunk-Router dieser Hoods einsammelt und diese auf Port 4000 per http zur Verfügung stellt (siehe zB http://os02.sn.ffnw.de:4000/nodes.json ) . Der Server, auf dem unsere Freifunk-Karte liegt, holt die Daten von dort regelmäßig ab, speichert sie mit den Daten anderer Hoods zwischen und sorgt für deren Aktualisierung. Das „Einsammeln“ der Daten wird dabei von einem kleinen Nodejs-Script erledigt. Ein funktionierender Ansatz, aber mit viel Optimierungspotenzial:

  • Das Script, welches die Daten von den Hood-Servern einsammelt, bildet eigentlich nichts Anderes als einen Cache. Warum also an dieser Stelle nicht auf ein bewährtes, fertiges,performantes Caching-System zurückgreifen?
  • Die Server liefern die Daten als unkomprimiertes json (große Datenmengen!)
  • Das Datenformat ist eine Eigenentwicklung, warum nicht etwas standardisiertes wie zB netjson oder geojson verwenden?
  • Das Script erzeugt manchmal verhältnismäßig viele Prozesse und viel Last

Daraus entwickelte sich der folgende Lösungsansatz:

  • Auf dem Map-Server wurde die Konfiguration des verwendeten nginx-Webservers angepasst, sodass dieser Anfragen nach Daten aus den jeweiligen Hoods zunächst zentral entgegen nimmt und diese dann als Proxy an den zuständigen Hood-Server weiterleitet:

(Definiton eines Cache in der nginx.conf:)

proxy_cache_path /tmp/nginx/ keys_zone=one:10m levels=1:2;

(Aktivierung der Weiterleitung (proxy) und gzip-Komprimierung für die *.json-Dateien:)

location ~ /ll-dataproxy/hoods/([^/]+)/ { 
                proxy_cache_lock on; 
                proxy_cache_valid any      1m; 
                proxy_cache_lock_age 5s; 
                proxy_cache one; 
                resolver 8.8.8.8; 
 
                gzip on; 
                #gzip_proxied any; 
                gzip_types application/json; 
 
                rewrite    /ll-dataproxy/hoods/([^/]+)/(.*) /$2 break; 
                proxy_pass http://$1.sn.ffnw.de:4000; 
}
  • Damit dies nicht bei jeder Anfrage erneut passieren muss, ist an dieser Stelle auch ein Cache eingerichtet, der nach einer Minute erneuert wird. Die Daten für jede Hood sind damit gemäß dem Schema https://srv11.ffnw.de/ll-dataproxy/hoods/os02/nodes.json erreichbar.
  • Ebenfalls in der nginx-Konfiguration wurde gzip aktiviert (siehe oben), wodurch die Daten zur Übertragung stark komprimiert werden können. Insbesondere bei den json-Dateien, die häufig Listen Hunderter Elemente mit jeweils gleichnamigen Subelementen besitzen, kann die gzip-Komprimierung glänzen und staucht die Dateien teilweise auf bis zu 1/10 ihrer ursprünglichen Größe zusammen!
  • Auf einem Freifunktreffen empfahl Oliver die Verwendung von geojson, da dies von leaflet direkt verarbeitet werden kann. Unter https://srv11.ffnw.de/ll-dataproxy/hoods/os02/geojson/nodelist.json und https://srv11.ffnw.de/ll-dataproxy/hoods/os02/geojson/graph.json können die geojson-Dateien für Knoten und Meshverbindungen abgerufen werden.

Mit dieser Konfiguration haben wir die Datenverarbeitung auf der Serverseite erheblich robuster und effizienter gestaltet. Die Daten können nun auch wesentlich schneller und weniger traffic-intensiv abgerufen werden. Der nächste Schritt ist nun, das entsprechende Gegenstück für den Browser zu schreiben, was durch diese Grundlage einfacher als zuvor möglich sein wird. Dann steht einer neuen Map, die bei gängiger Hardware und Internetverbindung gut funktioniert nichts mehr entgegen.

Wir halten euch auf dem Laufenden.

Monitoring and quality assurance of open wifi networks out of client view (final evaluation)

Hi together,

now the time has come to explain the full Google Summer of Code Project. In both blog posts before I explained the work packages and structure of the Project [0][1]. In the first post I declare the three main subjects. Here is a short overview to remind of the project structure:

sub-projects,

Mainline project

and seminars.

The sub-projects are background work for community projects.

The mainline Google Summer of Code project is to develop a new firmware for routers, based on LEDE [2]. The third point are seminars for enlightment of technical aspects of the Freifunk Community. (mehr …)

Monitoring and quality assurance of open wifi networks out of client view (midterm evaluation)

Hey everyone,
Now we are on the midterm evaluation. I would like to tell you what I have done so far and what will come next. In the first post [0] I explained the work packages. In this post I will come back to the work packages  and show you what I have done for each package.
The first sub-project was the hoodselector. At the beginning of the work period I did some bugfixing for the hoodselector so that we where able to deploy the hoodselector in our live environment. The hoodselector creates decentralized, semi automated ISO OSI layer 2 network segmentations. You can find a detailed discription here [0]. Retrospective I can say that the deploymend of the hoodsystem went without any major problems opposed to my first expectations. Currently we have 4 hoods active. Around Oldenburg(Oldb), Ibbenbüren, Osnabrück and Friesland. More hoods will follow in future. Open Issues can be find here [1].
The second sub-project was to create a propper workaround for building images with the continuous-integration (CI) system of Gitlab using make on multiple cores.
The Freifunk Nordwest firmware now has automatically built testing images that are not only build on a single core but can be built on multiple cores. And the architecture targets are also autogenerated out of the sourcecode. This makes it possible to generate images dynamically for all
targets also including new targets that may come in the future. I implemented a small algorithm that manages the thread counter of make commands. I
use the number of CPUs out of /proc/cpuinfo * 2 this means for each logic core will follow two threads. In example our runner02.ffnw.de server has 8 cores so the CI build process will automatically build with 16 Threads [2]. Here is an example of a passed buildprocess with our CI builder[3]. Actually it is not possible to build images with a high verbose output, because the CI logfiles will get to big. That makes it impossible to use the webfrontend for analyzing the buildprocesses. I opened an issues for this and discussed the problem with the gitlab developers [4].
The CI builder is very helpful for the developing process of the monitoring drone.
Following I would like to report about our first hacking seminar.
The first hacking seminar was on 28.05.2016. We started with two presentations. One about Wireless Geo Location and the second one about the Hoodselector. We recorded the presentation with our new recording equipment [7] bought using some of the money for the mentoring organisation and uploaded the recordings to youtube [5].
The first presentation was about geolocating with wireles technologies.
Based on the Nordwest Freifunk geolocator [6]

The second presentation was about the function of the Hoodselector


After this two presentations we had a smal disscussion about the presentation topics and than we started o
ur hacking session where the developers started coding on their projects.
Now all sub-Projects are finnisched and I will continue with the Monitoring Drone Project after I finish my Study exams. Also the date of next hacking seminar is set for 9th of Juli 2016. Again we will have two presentations. One on Gitlab CI and one about how to use our new Puppet Git repositories including the submodule feature. The presentations will be recorded and after the presentation we will have a coding session like last time.
Timeline:
23. May: Community Bonding (3 weeks)
test and deploy hoodselector  <- Done
16. May 6:00 PM: GSoC Mumble  <- Done
Refine the roadmap  <- Done
23. May – 20. June: Work period 1 (4 weeks) <- Done
28. May 2:00 PM: hacker-session  <- Done
  1. Presentation about the hoodselector <- Done
  2. Presentation about the openwifi.su project[4] and the geolocator <- Done
13. June 6:00 PM: GSoC Mumble  <- Done
Midtermevaluation
Tarek & Clemens exams!!!
20. June – 15. August: Work period 2 (8 weeks)
9. July 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. Presentation about puppet deployment system
13. June 6:00 PM: GSoC Mumble
25. June 2:00 PM: hacker-session
  1. Presentation about workaround with git CI processes.
  2. Presentation about puppet deployment system
18. July 6:00 PM: GSoC Mumble
30. July 2:00 PM: hacker-session
  1. actual unknown
  2. actual unknown
15. August 6:00 PM: GSoC Mumble
Finalevaluation

Neuer Meshviewer (MAP)

Von vielen Nutzern unseres Freifunk Netzes wurde es gewünscht – wir haben seit einigen Tagen eine eigene Meshviewer (MAP) Instanz unter https://map.ffnw.de installiert. Der Meshviewer (MAP) ersetzt das Netmon vollständig – vor einigen Jahren wurde das Netmon für wenige Router programmiert. In den letzten Monaten zeigten sich immer wieder größere Probleme mit dem Netmon, sodass man über seine Router keine weiteren Statusdaten mehr abfragen konnte.

Unterschiede zum alten Meshviewer:

  • Der Meshviewer (MAP) läuft im Freifunk Nordwest Netz mit TLS
  • Meshviewer (MAP) wurde auf Version 4 geupdatet
  • Offline Knoten werden nach 2 Tagen entfernt.

Sollten weitere Fragen zur neuen Nordwest Meshviewer (MAP) entstehen sprecht uns einfach an.