Neuer Tunnel: L2TP statt FastD

Bisher setzen wir im Niersufer als VPN-Tunnel-Protokoll den „Fast and Secure Tunnelling Daemon“ kurz „fastd“ ein. Dieser sorgt nicht nur auf den Routern selber für soviel Last, dass die kleineren Modelle nur wenige MBit/s Bandbreite liefern können, auch auf unseren Supernodes bereitet uns „fastd“ einige Bauchschmerzen.

Der Grund dafür ist, dass „fastd“ unter Linux im Userspace läuft, sämtliche sonstige Netzwerkkommunikation (mit der Netzwerkkarte, mit dem B.A.T.M.A.N.-Protokoll für Freifunk) aber im Kernerl stattfindet. So muss für jedes Datenpaket der Kontext zwischen Kernel- und Userspace gewechselt werden, was hohe CPU-Last erzeugt. Die Supernodes schaffen auf Grund ihrer potenten Hardware zwar trotzdem ein paarhundert MBit/s, sind aber was die CPU-Last angeht ziemlich am Rande dessen, was noch vertretbar ist.

Als Alternative könnte man nun weitere Supernodes in Betrieb nehmen, um die Last in der Breite zu verteilen oder den Supernode-VMs mehr CPU-Leistung zuteilen, damit diese nicht mehr ausgelastet sind. Irgendwann muss man sich dann aber auch fragen, ob es Sinn macht, die Designprobleme mit „fastd“ durch immer mehr Leistung – und dadurch auch durch immer mehr Energie – zu kompensieren. Wir haben für uns nun entschieden, dass es keinen Sinn mehr macht.
Daher werden wir in Zukunft das „Layer 2 Tunneling Protocol“ kurz „L2TP“ als Tunnelprotokoll und Tunneldigger als Dienst einsetzen – wie das bereits einige andere Freifunk Domänen heute schon tun.

Um mal ein paar Zahlen zum Vergleichen zu nennen: ein kleiner TP-WR841N/ND schafft mit „fastd“ knapp 10 MBit/s Bandbreite, mit „L2TP“ schafft er ohne Probleme 50 Mbit/s und mehr.

Verschweigen wollen wir allerdings auch nicht, dass „L2TP“ im Gegensatz zu „fastd“ keine Verschlüsselung der Daten mehr bietet. Die Daten werden „nur“ im Tunnelprotokoll eingekapselt und dann an unsere Supernodes geschickt. Rechtlich hat das allerdings keine Relevanz.

Wir arbeiten aktuell an den Firmware-Images mit „L2TP“-Unterstüzung und zeitgleich werden die Supernodes fit für „L2TP“ und Tunneldigger gemacht. Die ersten Images sollten bald zum Testen bereitstehen.

Anfangs werden wir „L2TP“ und „fastd“ parallel betreiben, mittefristig wird aber komplett auf „L2TP“ umgestellt werden. Für „L2TP“ müssen ggf. in eurer Firewall neue/andere Ports freigeschaltet werden:
4215 (Netz Niersufer)
4216 (Netz Mönchengladbach)4217 (Netz Moers)

Vorerst kein Update auf Gluon 2016.1

Vor ein paar Tagen wurde die neuste Gluon Version (2016.1) offiziell released. Da es offensichtlich aber noch einige Bugs im aktuellen Release gibt, wovon wir den ein oder anderen als kritisch einstufen, wird es im Niersufer vorerst kein Update auf Gluon 2016.1 geben.

Wir wissen natürlich, dass viele händeringend auf die neue Version warten, weil einige neue Hardware (beispielsweise der TP-Link TP-WR841N/ND v10) erst von dieser unterstützt wird. Deshalb werden wir eine Firmware auf Basis von Gluon 2016.1 als „Experimental“ rausgeben. Jeder, der diese Firmware für sein Gerät braucht, kann sie dann händisch flashen. Bitte dabei im Hinterkopf behalten, dass diese Geräte bei Erscheinen des „Stable“-Updates erst dann wieder automatisch ein Update erhalten werden, wenn in der Konfiguration des Auto-Updaters der Branch auf „stable“ gesetzt wird.

Wir arbeiten zur Zeit unter Hochdruck daran, diese Firmware-Images für alle Netze zu bauen.

[fixed] Meshviewer funktioniert nicht

Aktuell haben wir leider ein paar Probleme mit dem Server, der die Daten für die Karten erstellt. Dadurch funktionieren die Meshviewer in den Communities sowie unsere Statistiken derzeit nicht.

Wir arbeiten an einer Lösung.

UPDATE

Die Probleme konnten gelöst werden, die Kartendaten werden wieder wie gewohnt erzeugt und die Communities haben wieder einen funktionierenden Meshviewer und aktuelle Statistiken.
Danke auch an Manuel Trier für seine Mithilfe.