Neue Firmware 1.2.2

Gestern war zwar nicht Freitag der 13., aber der Tag des Fehlerteufels in unserer Firmware.
Irrtümlicherweise war das 1.2.1-Release auf Testing konfiguriert.

Basisdaten:
 * Firmware-Version: 1.2.2
 * Gluon-Version: v2016.1.x
 * Commit ID: 8c9504bccb1899325f1dfb2a5a292074a6f9173c
 * Download: https://firmware.ffnw.de/1.2.2/

Folgende Comunnity spezifischen Änderungen gab es:
siteconf:
Konfiguration von SSID etc. auf Produktivbetrieb

Neue Firmware 1.2.1

In den nächsten Stunden wird im Freifunk Nordwest Netz eine neue Firmware ausgerollt. Leider hat die Version 1.2 einen Fehler enthalten, sodass Router mehrere öffentliche IPv6 Adressen er- und behalten haben.

Basisdaten:
 * Firmware-Version: 1.2.1
 * Gluon-Version: v2016.1.x
 * Commit ID: ee597c66769a455d38467192598813e7f8411cfd
 * Download: https://firmware.ffnw.de/1.2.1/

Folgende Comunnity spezifischen Änderungen gab es:
package repo:
* Kritischer Fehler im multiple-v6-watchdog:
  Dieser schaute nur nach GLEICHEN v6 Adressen,
  nicht nach unterschiedlichen aus den Hoods. 
  Dieser Fehler wurde behoben.

Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/v1.2...v1.2.1

Die Änderungen an unseren eigenen Paketen können im Packages-Repository
hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/v1.2...v1.2.1

Neue Firmware 1.2

In den nächsten Stunden wird im Freifunk Nordwest Netz die neue Firmware 1.2 ausgerollt. Alle Router, die den Autoupdater auf den Branche „stable“ aktiviert haben, erhalten dies automatischt.

 * Firmware-Version: 1.2
 * Gluon-Version: v2016.1.x
 * Commit ID: ee597c66769a455d38467192598813e7f8411cfd
 * Download: https://firmware.ffnw.de/1.2

Die upstream Änderungen findet ihr hier:

https://github.com/freifunk-gluon/gluon/compare/ee597c...ee597c

Folgende Comunnity spezifischen Änderungen gab es:
package repo:
* logic Fehler im configmode wurden behoben
    Das Dropdown menu hat, bei wiederholten ausführen des
    configModes seinen zustand nicht wiederhergestellt.
    Das setzen zweier uci Parameter ist durch einen Typen Fehler
    nie zu Stande gekommen.

* Client seitige Javascript map im configeMode
    Es wird nun vom Router aus via Javascript auf den Client eine
    OSM Karte geladen, sofern der Client über eine Internet
    Verbindung verfügt. Um das selektieren von statischen Geo
    Koordinaten zu vereinfachen.

* hoodselector: hoodinfo Sektion in respondd wurde erstellt #63 #48
    Über respondd werden nun Informationen über die aktuell
    selektierte hood eines Routers verteilt.

* hoodselector: das MOLWM Protokoll wurde implementiert Mesh On Lan
/ Wan Managemend
    Das MOLWM Protokoll detektiert hood Kollisionen im mesh on lan
    oder mesh on wan. U.a. anhand von Vergleichungen von md5 hashes
    der einzelnen hoods.

* hoodselector: Der hoodselector gibt nun returncodes bei der
Terminierung zurück.

* hoodselector: pid datei write Permission wird abgefangen

* hoodselector: Unbenutzte variablen wurden entfernt und das überlappen
von Globalen variablen wurde behoben (zum Einsatz kam luacheck)

* hoodselector: Es können nun mehrere fastd peers mit äquivalenten DNS
aber unterschiedlichen Port bestehen. #40
    Das ermöglicht uns anstelle von folgenden zu schreiben:
      starwars0.sn.ffnw.de 1001
      starwars1.sn.ffnw.de 1010
      starwars1.sn.ffnw.de 1011

    Lediglich:
      starwars.sn.ffnw.de 1001
      starwars.sn.ffnw.de 1010
      starwars.sn.ffnw.de 1011

    Das reduziert somit die ganzen DNS Einträge.

* hoodselector: Im scanmode arbeitet der hoodselector nun nicht mehr mit
einen statisch festgelegten WLAN Interface, sondern scannt über alle WLAN
Interfaces die ein Gerät hat. #69

* hoodselector: Im scanmode wird nicht mehr statisch 30 sec abgewartet
um anschließend zu prüfen ob eine mesh Verbindung besteht. Es wird nun
kontinuierlich geschaut und spätesten nach einem Zeitablauf von 30 sec
fortgesetzt. #70

* hoodselector: Fehlermeldungen werden nun in ein logfile geschrieben und
können und über logread eingesehen werden. #36

Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/v1.1.1...v1.2

Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/v1.1.1...v1.2

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.

Jetzt Förderung beantragen!

20160916_140554
Die Routenhardware für Niedersachsen ist bereits eingetroffen

Förderantrag jetzt ausfüllen!

In vielen Treffen und Gesprächen in Hannover haben wir seit März mit dem Landtagsabgeordneten und dem Breitband Kompetenzzentrum zusammengesessen und eine Verfahren erarbeitet, die Fördergelder möglichst umkompliziert den Freifunkern zur Verfügung zu stellen. Dabei wurde ein Großteil der Gelder nun in Routerhardware investiert. Diese Router, meist vom bekannten Hersteller TP-Link, können durch einen entsprechenden Antrag abgerufen werden. (mehr …)

Förderung durch das Land Niedersachsen

Informationspolitik und ehrenamtliche Zeit als hohes Gut

wirtschaftsministerium-foerdert-freifunk-initiativen-im-land-520x245
Wirtschaftsministerium fördert Freifunkinitiativen im Land

In den letzten Woche pocht das Thema Freifunk immer öfter, durch die Verhandlungen über die Störerhaftung in den Medien auf. Schnell vergessen ist dabei, dass Anfang des Jahres durch einen Antrag der Grünen und der SPD eine Förderung des Freifunks in Niedersachsen bewilligt worden ist. Grundsätzlich ging es dabei um zwei entschiedene Dinge: Zum einen eine geldliche Förderung in Höhe von 100.000 Euro und zum anderen eine Info- und Aufklärungskampagne von Städten und Kommunen über das Thema Freifunk, welche für uns ebenfalls sehr wichtig ist. (mehr …)