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.

Zwischenstand zweite Woche nach Firmware Version 0.5.6

Zwei Wochen sind vergangen seit wir das Netz mit dem Update auf Firmware Version 0.5.6 mit einer neuen, zum Vorgänger inkompatiblen Version des Mesh-Protokolls Batman advanced versorgt haben. Im Zuge des Updates haben wir in den vergangenen Tagen noch drei kleinere Updates hinterher geschoben und stehen mittlerweile bei Firmware Version 0.5.6.3.

Durch die Updates sind seit gestern Nachmittag, mit Ausnahme von vpn01.ffnw.de, alle Supernodes wieder online, sodass keine Fehler aufgrund von Kapazitätsengpässen an den Supernodes mehr auftreten sollten. Das heißt, alle Nodes sollten nun wieder eine stabile Verbindung aufbauen können, wobei Netmon derzeit aus unten genannten Gründen dafür kein sicherer Indikator ist. Zum prüfen der Verbindung muss derzeit noch ein manueller Test erfolgen. Unsere erste Supernode vpn01.ffnw.de wird noch ein paar Wochen mit der alten Batman advanced Version laufen um die verbliebenen ca. 20 Router mit Altfirmware am Netz zu halten.

Dennoch sind nach noch nicht alle Probleme behoben. Da wir uns zum größten Teil ganz auf die Lösung der Netzprobleme konzentriert haben, gibt es noch Fehler an unserem Netmon:

  • Das Eintragen neuer Router ist nicht möglich, da IP-Adressen nicht eingetragen werden
  • Der Crawler scheint noch nicht vollständig korrekte Werte zu liefern

Das beheben dieser Fehler ist nun für die dritte Woche vorgesehen. Wenn alle Fehler behoben sind ist für die vierte Woche eine Evaluation des Updates geplant um herauszufinden welche Nodes wir bei dem Update verloren haben um diese manuell wieder online bringen zu können.

Zwischenstand des Firmware Updates 0.5.6

Im großen und ganzen hat das Firmware Update auf die Version 0.5.6 und das damit einhergehende große Update des Mesh-Protokolls wie geplant funktioniert und der überwiegende Teil der Router konnte auf die neue Version updaten. Es treten derzeit jedoch insbesondere bei unseren Supernodes und beim Monitoring noch einige Probleme auf, die sich nicht in kurzer Zeit lösen lassen.

Da die Probleme bekannt sind, bitte wir von kurzfristigen Anfragen abzusehen. Bitte gebt den Leuten die daran arbeiten etwas Zeit die Probleme zu fixen. Anschließend können wir gemeinsam evaluieren was gut gelaufen ist und was Probleme bereitet hat. Wir möchten an dieser Stelle auch ein wenig den Druck von den Admins und Entwicklern nehmen, die im Moment überdurchschnittlich viel Freizeit investieren.

Firmware 0.5.6: Achtung, grundlegende Änderung!

Hallo,

Vorab: Wichtig für euch ist:

Bitte den Router, insbesondere, wenn es ein reiner Mesh-Router ist, am Dienstag, den 09.06.2015 zwischen 8 Uhr morgens und 17 Uhr nicht vom Netz nehmen oder ausschalten, damit er wie unten beschrieben ordnungsgemäß sein Update installieren kann!
Die Netmon-Anzeige hat in den nächsten Tagen – bis das Update vollständig abgeschlossen ist – keine Funktion/Aussagekraft.

auf unserem gestrigen Freifunk-Treffen in Osnabrück haben wir uns nun abschließend darauf verständigt, den Schritt in Richtung Firmware 0.5.6 zu machen.

Hierbei handelt es sich nicht um eines der kleineren 0815-Updates, die in den letzten Wochen und Monaten hauptsächlich dafür da waren, kleinere Fehler zu beheben oder neue VPN-Gateways hinzuzufügen. Stattdessen wird mit dieser Version das gesamte Netz von der bisher verwendeten 2013er-Version des B.A.T.M.A.N-Protokolls auf eine neuere, 2014er-Version aktualisiert. Da dieses Protokoll für das Meshing der Freifunkrouter untereinander zuständig ist und bei diesem Versionssprung keine abwärtskompatibilität gegeben ist, wirft dies einige Probleme auf.

Router mit unterschiedlichen Firmwareversionen (<0.5.6 gegenüber >=0.5.6) sind nicht in der Lage, miteinander zu kommunizieren. Auch können sich Router mit älterer Firmware/B.A.T.M.A.N-Version künftig nicht mehr mit den VPN-Gateways, die die neuere B.A.T.M.A.N-Version fahren, verbinden. Es ist somit dann kein Netzzugang für diese Firmware-Versionen möglich.

Um Routern, die zur Zeit des geplanten Updates gerade – warum auch immer – offline sind, dennoch die Möglichkeit des Autoupdates zu geben, werden wir kurzfristig (wenige Tage bis Wochen) einige der VPN-Server noch auf der alten B.A.T.M.A.N-Version laufen lassen.

Problematisch beim bisherigen Autoupdate-Mechanismus wäre für dieses Update die Versorgung der reinen Funk-Mesh-Router ohne eigenen Internetanschluss gewesen: Würden diejenigen Router, über die diese an das Internet angebunden sind, zuerst das Update einspielen, wäre die Verbindung zu den Mesh-Routern wegen der beschriebenen fehlenden Abwärtskompatibilität nicht mehr möglich und diese würden dauerhaft auf der alten Firmware festhängen und vom Netz abgeschnitten sein.

Aus diesem Grund ist bereits in der aktuellen Firmware-Version eine modifzierte Version des Autoupdaters enthalten, die dafür sorgt, dass sich sämtliche Router zunächst das Update herunterladen und anschließend zuerst und mit 4 Stunden Zeitvorsprung die reinen Mesh-Router das Update einspielen. Für die nächsten 4 Stunden sind diese dann nicht online, bis die restlichen Router nachziehen, die Verbindung wieder aufgebaut werden kann und anschließend wieder alles wie gewohnt funktionieren sollte.

Wir haben diesen Schritt ausführlich diskutiert und uns überlegt, ob es Sinn macht, ein anderes, als dieses verhältnismäßig einfache, zeitbasierte Updateverfahren zu implementieren, haben in einigen Praxistests aber mit diesem Verfahren sehr gute Ergebnisse erzielt.

Drücken wir die Daumen, dass alles wie geplant funktioniert, dann haben wir Dienstag Abend ein Netz, das in seiner technischen Entwicklung auf einen Schlag über ein Jahr reifer ist 😉