Kleine Warnung vorweg: es wird wieder verstärkt an der Firmware gearbeitet, bei Geräten im »experimental«-Zweig könnte es versehentlich scheppern …
Wir planen derzeit nicht, auf Gluon v2016.1 umzusteigen und, was vorab käme, unsere Änderungen zu portieren; unter anderem gibt es aktuell dort Probleme mit der MAC-Adresse des WAN-Interfaces, und mit dem Schritt auf v2015.1.2 aka Firmware 0.7.x im September haben wir u. a. das Holiday Inn wegen der MAC-Adressen-Änderung, die wir uns mit v2015.1.2 unbewußt eingefangen hatten, verloren.
Aktuelle Änderungen, die in den nächsten »experimental«-Releases ausprobiert werden:
- Wegfall des lustigen Ethernet-Port-Roulettes.
Die Installation soll zukünftig immer über ›WAN‹ erfolgen, so vorhanden. Dies vereinfacht ganz generell die Installation und sorgt für weniger versehentliche Fehlverbindungen.
- Erweiterung/Ersetzung des Tunnels auf/durch L2TP bzw. »tunneldigger«
fastd, die aktuelle Umsetzung für den VPN-Tunnel, läuft im Userspace, und das ist der Hauptgrund, warum auf den Freifunk-Knoten bei 8-25 MBit/sec, je nach CPU-Geschwindigkeit, Schluß ist: jedes Paket läuft mehrfach von Kernel- in den Userspace und wieder zurück. Bei L2TP bleiben die Pakete im Kernel, sodaß signifikant höhere Durchsätze möglich werden — mit der gleichen, kleinen Hardware.
L2TP bietet zwar keine Verschlüsselung des Traffics, aber da es jedem Datentransporteur sowieso verboten ist, in die Daten reinzugucken, und wir ohnehin Daten, die aus einem unverschlüsselten WLAN kommen oder dahin gehen, transportieren, ist dies sicherheitstechnisch kein Nachteil. Davon abgesehen, ist L2TP das Standardprotokoll für Tunnel im Internet, sowohl bei DSL-Anbietern als auch z. B. beim Telekom-Fon-Hotspot.
Ein anderer Grund für die Zurückhaltung bzgl. Gluon v2016 ist, daß wir unsere Änderungen leider nicht als Add-On-Pakete für Gluon auslegen können, sondern die zentralen Gluon-Pakete anfassen müssen (Gluon-Kernpakete können lt. Aussage der Entwickler nicht ersetzt werden). Nach v2014 und v2015 verliert dies bei v2016 langsam dann doch seinen Reiz. Da wir mit diversen grundlegenden Entscheidungen nicht konform gehen – und das fängt eben schon bei der Wahl des Installationsinterfaces an –, ist eine einfache Nutzung des nackten Gluon-Codes somit nicht machbar.
Zwar bietet Gluon v2016, neben erweitertem Hardware-Support, auch das Meshing-Protokoll 802.11s neben dem veralteten AdHoc-Modus, und mittelfristig werden wir evtl. darauf schwenken; aber im Grunde sind wir mit dem aktuellen Status unter Stabilitätsgesichtspunkten zufrieden, daher erst einmal keine Experimente in diese Richtung.
Kurzum: Geräte mit »experimental«-Firmware werden demnächst kurzfristig und wiederholt neue Firmwares laden, die entsprechenden Knotenbetreiber seien entsprechend vorgewarnt ;)