© Dzmitry Dzemidovich / 123RF.com

Das OpenWrt-Projekt verspricht herstellerunabhängige WLAN-Administration aus einem Guss. Genau darum geht es im letzten Teil unserer kleinen Serie.

OpenWrt ist ein großartiges Open-Source-Projekt, das dabei helfen kann, WLAN-Router, Access Points und Repeater auch unabhängig vom Hardwarehersteller in einer einheitlichen Art und Weise zu betreiben. Bei der Auswahl der Hardware gilt es allerdings zu beachten, dass OpenWrt manche Geräte mangels verfügbarer Open-Source-Treiber nicht oder nicht vollständig unterstützt.

So gibt es beispielsweise derzeit keine verfügbaren Open-Source-Treiber für DECT-Hardware und auch nicht für VDSL2. Bei einigen Chipsätzen, etwa von Marvell und Broadcom, ist der Funktionsumfang eingeschränkt. Bei manchen lassen sich nicht alle WLAN-Frequenzbereiche nutzen, für andere gibt es keinen 802.11s-Support (Mesh-Networking). Die neueren WLAN-Roaming-Protokolle 802.11k und 802.11v unterstützt OpenWrt ebenso wenig (zumindest nicht im derzeitigen Stable Release 19.07.x) wie 802.11ax. Für Anwendungen benötigt man diese Features jedoch auch nicht zwingend.

Bevor Sie eine Komponente mit OpenWrt bestücken, sollten Sie also einen Blick in die OpenWrt Table of Hardware [1] werfen, besonders, wenn Sie das Gerät gezielt kaufen wollen, um es auf OpenWrt umzurüsten. Die Auswahl ist aber trotz dieser Einschränkungen riesig. Tendenziell unterstützt OpenWrt ältere Geräte besser als brandneue. Aber Achtung: Modelle mit 4 MByte Flash oder weniger und Geräte mit 32 MByte RAM oder weniger lassen sich ab der kommenden Version 20.x nicht mehr nutzen; OpenWrt passt dort schlicht nicht mehr in den Speicher.

Sofern der Hardware-Support passt und Sie weder DECT noch VDSL2 benötigen, eignet sich OpenWrt jedoch bestens, um auch ältere Hardware sinnvoll und sicher weiter zu nutzen. Freilich lässt es sich nicht nur auf alter Bastelhardware einsetzen, sondern auch auf Geräten der Business-Klasse – das Turris OS auf Turris Omnia basiert zum Beispiel auf OpenWrt.

Der Funktionsumfang von OpenWrt schlägt die meisten kommerziellen WLAN-Betriebssysteme in Sachen Flexibilität und Update-Fähigkeit um Längen. Proprietäre Management-Lösungen gibt es hier freilich nicht. Dafür haben Sie vollen Root-Zugriff auf ein Linux-System mit all seinen Möglichkeiten. Die inhaltliche Konfiguration eines OpenWrt-Systems für einen bestimmten Zweck ist jedoch nicht Gegenstand des vorliegenden Artikels.

Installation

Die Installation von OpenWrt kann je nach Gerät sehr unterschiedlich ausfallen. Wir behandeln sie in diesem Artikel aus Platzgründen nicht im Detail. Die Verfahren reichen vom einfachen Hochladen über das Einspielen über die originale Weboberfläche (viele TP-Link-Geräte) und spezielle Skripte plus TFTP-Server (viele Fritzboxen) bis hin zum Aufschrauben und Löten (etwa bei Access Points von Aruba). Dabei gilt es, jeweils das richtige OpenWrt-Binary-Image für genau das vorhandene Modell zu verwenden. Auch hier ist die Table of Hardware der richtige Anlaufpunkt.

Es kann aber durchaus vorkommen, dass Sie sich in die Tiefen des OpenWrt-Forums begeben müssen, um die meist eher spärlichen Informationen auf den OpenWrt-Seiten anwenden zu können. Lassen Sie dabei Vorsicht walten: Wie in jedem Forum finden Sie nicht nur jede Menge Hilfe, sondern auch sehr viele völlig veraltete Einträge und Anleitungen. Es lohnt sich immer nachzusehen, von wann eine Information stammt und ob sie nicht vielleicht schon seit Jahren überholt ist.

Prinzipiell können Sie OpenWrt auch selbst aus den Quellen kompilieren, die Build Chain ist gut dokumentiert. Das erfordert aber einiges an Wissen und Handarbeit sowie einen gut ausgestatteten Rechner. Sie müssen ja nicht nur den Kernel übersetzen, sondern vorher die passenden Cross-Compiler und Build-Tools sowie alle Module und Anwendungen, die Sie nutzen möchten.

Konfigurationsmanagement

Ist OpenWrt erst einmal aufgespielt, verläuft die Administration stets gleich. OpenWrt verwaltet seine Konfiguration mit dem Befehlszeilenwerkzeug Unified Configuration Interface (Uci [2]). Daneben gibt es die in LUA [3] geschriebene Web-GUI LUCI [4], die im Wesentlichen nichts anderes tut, als die Konfigurationsdateien hinter den Kulissen in Uci-Befehle umzusetzen, Opkg zu verwalten und einige Informationen anzuzeigen.

Allerdings lassen sich nicht alle Konfigurationsoptionen über LUCI erreichen, sodass für komplexere Aufgaben meist kein Weg um die Arbeit auf der Befehlszeile herumführt. Achtung: Speichert LUCI eine Konfigurationsdatei neu, überschreibt es ein vorhandenes Exemplar komplett, was bedeutet, dass alle eventuell manuell eingefügten Kommentare verloren gehen. OpenWrt hält die durch Uci verwalteten Konfigurationsdateien im Verzeichnis »/etc/config/« und erwartet, dass dort nur Uci-Konfigurationen liegen. Andere Dateien führen zumindest zu Fehlermeldungen, können aber auch die Funktion von Uci stören.

Die wichtigsten Konfigurationsdateien sind »/etc/config/network« für Ethernet-Schnittstellen, den meist eingebauten Switch sowie für DHCP, die Nameserver-Konfiguration und so weiter sowie »/etc/config/wireless« für alles, was mit WLAN zu tun hat. Nicht von Uci verwaltete Pakete lagern ihre Konfigurationsdateien wie gewohnt unter »/etc«, beispielsweise Dropbear für den SSH-Zugriff.

Sehr sinnvoll ist es, die Funktion des Konfigurationsmanagers Uci durch Uci-extras [5] zu erweitern (Listing 1). Das Skript erleichtert es enorm, die bestehende Konfiguration zu überprüfen und Änderungen zu finden.

# opkg update
# opkg install libustream-mbedtls
# uclient-fetch -O uci-extras.sh "https://openwrt.org/_export/code/docs/guide-user/advanced/uci_extras?codeblock=0"
# . ./uci-extras.sh

OpenWrt und Updates

Die OpenWrt-Entwickler warnen auf der Webseite des Projekts eindringlich vor Paket-Updates [6]: Die Konsistenz des Systems lasse sich in diesem Fall nicht sicherstellen. In der Praxis gibt es mit den Updates aber nur selten Probleme, solange man nicht versucht, Core-Pakete zu updaten. Anwendungsprogramme bereiten dagegen meist keine Schwierigkeiten.

Allerdings können Paket-Updates die im ROM befindlichen Pakete aus dem System-Image nicht überschreiben. Die Aktualisierungen landen stattdessen im Flash-Overlay, sodass der Flash-Speicher bei häufigen Updates mit der Zeit vollläuft. Das erzwingt dann in der Folge ein System-Upgrade oder zumindest das Löschen nicht dringend benötigter Pakete – ein Grund mehr, Geräte mit möglichst viel Flash-Speicher zu verwenden. Aus Sicht der IT-Sicherheit erscheint freilich eine Strategie fatal, derzufolge man niemals Pakete aktualisiert und nur System-Upgrades einspielt.

OpenWrt verwendet für das Paketmanagement den Paketmanager Opkg, der allerdings nur eine beschränkte Funktionalität bietet – es gibt beispielsweise kein »update all«. Dafür muss man sich entweder selbst Skripte bauen oder greift zum inzwischen verfügbaren Skript Opkg-extras [7], das im Web verfügbar ist. Seine Installation demonstriert Listing 2.

# opkg update
# opkg install libustream-mbedtls
# uclient-fetch -O opkg-extras.sh "https://openwrt.org/_export/code/docs/guide-user/advanced/opkg_extras?codeblock=0"
# . ./opkg-extras.sh

Bevor Sie mit Opkg arbeiten, sollten Sie immer als Erstes ein »opkg update« vornehmen, da die Paketliste einen Neustart nicht überlebt. Das Script Opkg-extras erweitert die Funktionalität von Opkg um Befehle wie “aktualisiere alles”, “finde neue Konfigurationen”, “installiere Pakete erneut” und einige mehr. Mit »opkg upgr au« lassen sich nun alle verfügbaren Updates einspielen.

Sofern Sie OpenWrt-Snapshots verwenden wollen oder müssen, gibt es bei Updates eine zusätzliche Stolperfalle: Naturgemäß ändert sich bei Snapshots häufig die Kernel-Version des Systems. Das bedeutet, dass Sie Updates für einzelne Pakete nur einspielen können, wenn sie nicht für eine neuere Kernel-Version gebaut wurden als die installierte. Eine neue Kernel-Version bedingt also zwangsläufig ein System-Upgrade.

System-Upgrades

OpenWrt ist ein lebendiges Projekt und liefert dementsprechend viele und häufige Updates, insbesondere zur Web-GUI LUCI. Nun handelt es sich bei den Geräten um Embedded-Systeme mit Flash-Speichern, die gemessen in Schreibzyklen eine deutlich geringere Lebensdauer haben als Festplatten oder SSDs. Überlegen Sie sich also gut, ob Sie wirklich jedes Update mitnehmen wollen. Sicherheitskritische Aktualisierungen sollten Sie aber auf jeden Fall einspielen.

Ein Upgrade auf ein neues OpenWrt-Release [8] erfolgt grundsätzlich über das Einspielen eines kompletten neuen Images. Dabei gehen allerdings alle Einstellungen verloren. Es gibt jedoch die Möglichkeit, in die Datei »/etc/sysupgrade.conf« Dateien und Verzeichnisse einzutragen, die über ein Systemupgrade hinweg gerettet werden sollen.

Zusätzlich fehlen nach einer Systemaktualisierung auch alle selbst installierten Pakete. Über die Jahre hat die Community etliche Skripte bereitgestellt, mit denen man dieses Problem (durch automatische Neuinstallation) verhindern kann. Eines dieser Skripte sollten Sie also unbedingt vor einem System-Upgrade installiert und angewendet haben. Erläuterungen dazu finden sich auf der OpenWrt-Webseite [9].

Besonders nutzerfreundlich ist das bereits genannte Skript Opkg-extras. Zusätzlich brauchen Sie noch das Erweiterungsskript Hotplug-extras [10], das Sie wie in Listing 3 gezeigt verwenden. Vor einer Systemaktualisierung sichern Sie dann mit »opkg save« die bestehende Konfiguration und stellen sie nach dem Upgrade mit »opkg update« und »opkg restore« wieder her. Eine Alternative bietet das Skript Opkgscript [11], mit dem Sie ebenfalls die Liste der installierten Pakete sichern und diese anschließend reinstallieren. Dazu rufen Sie erst »opkgscript.sh write« auf und nach dem System-Upgrade dann »opkgscript.sh -u install«.

# opkg update
# opkg install libustream-mbedtls
# uclient-fetch -O hotplug-extras.sh "https://openwrt.org/_export/code/docs/guide-user/advanced/hotplug_extras?codeblock=0"
# . ./hotplug-extras.sh

Eine Stolperfalle lässt sich mit solchen Workarounds jedoch nicht umgehen: Haben Sie nicht nur zusätzliche Pakete aufgespielt, sondern im jeweiligen Image vorhandene Pakete ersetzt (etwa Wpad-basic durch Wpad-mesh-openssl), dann läuft nach einem Upgrade wieder das ursprüngliche Paket, und das Nachinstallieren des Ersatzpakets schlägt fehlt. Pakete, die Komponenten des Standard-Images ersetzen, müssen Sie also manuell nachziehen, indem Sie zunächst das mitgelieferte Paket deinstallieren und anschließend das neue einrichten. Sinnvollerweise schreiben Sie dazu ein kleines Skript und tragen es in »/etc/sysupgrades.conf« ein, damit es eine Systemaktualisierung überlebt.

OpenWrt bietet keine Update-Benachrichtigung für installierte Software. Auch das gilt es, mit einem Skript selbst zu lösen. Mike Kuketz bietet dafür in seinem sehr lesenswerten Blog im Rahmen einer sehr guten Artikelserie zu OpenWrt [12] vorgefertigte Skripte [13] an. Die Skripte schicken via Cron gesteuert automatisch eine E-Mail-Benachrichtigung, sobald Aktualisierungen vorliegen.

Fehlende Pakete

Als Embedded-Systeme geizen WLAN-Geräte typischerweise mit Massenspeicherplatz (Flash), insbesondere ältere Modelle. Als rühmliche Ausnahme tun sich AVMs Fritzboxen hervor, die schon immer vergleichsweise üppig ausgestattet waren. Üppig bedeutet hier so etwas wie 128 MByte Festplatte und 256 MByte Flash. Wohlgemerkt: Megabytes, nicht Gigabytes.

Daher richtet das OpenWrt-Projekt seine Betriebssystemabbilder sehr stark aufs Platzsparen aus und hält sie möglichst klein. Auf der anderen Seite heißt das auch, dass man viele Softwarepakete nachinstallieren muss, sofern genug Platz bleibt. Manches ist reiner Komfort und hängt vom persönlichen Geschmack ab, manche Erweiterungen sind aber auch sicherheitsrelevant.

Die konkrete Softwareausstattung der Images für die verschiedenen Geräte unterscheidet sich teils deutlich. Hier fällt also ein wenig individuelle Nacharbeit an. Die meisten Abbilder der Version 19.07.x haben beispielsweise keine WPA3-Verschlüsselung an Bord, und der Webserver für LUCI kann im Standard-Image kein HTTPS, sondern nur HTTP. Sofern Sie den Modus »sae-mixed« für die eingerichteten Access Points verwenden, können sich Endgeräte sowohl über WPA2 als auch via WPA3 verbinden. Aber Achtung: Manche Endgeräte funktionieren damit nicht. In diesem Fall müssen Sie den Zugang wieder auf WPA2 beschränken.

Außerdem beinhalten die Images nicht immer die neuesten Versionen der Anwendungen. Um deren Installation nachzuholen, verwenden Sie die Kommandos aus Listing 4, das ein installiertes Opkg-extras voraussetzt. Der Befehl aus der vorletzten Zeile bereitet auch die Mesh-Installation vor.

# opkg update
# opkg list-upgradable
# opkg upgr all
# opkg remove wpad-basic
# opkg install wpad-mesh-openssl
# opkg install luci-ssl

Sofern Sie einen Snapshot einsetzen, fehlt auch das Web-Frontend LUCI, das Sie dann mit »opkg install luci luci-mod-admin-full« oder für HTTPS mit »opkg install luci-ssl luci-mod-admin-full« nachziehen.

Darüber hinaus ist es Geschmackssache beziehungsweise hängt vom Einsatzzweck ab, welche weiteren Tools Sie einrichten. Im Test-Setup für die Mesh-Installation hat sich in diesem Projekt die Zusammenstellung aus Listing 5 bewährt. Die letzte Zeile benötigen Sie nur, wenn Sie WLAN-USB-Sticks einsetzen wollen, die auf einem MT76-Chipsatz basieren. Diese preiswerten WLAN-Sticks funktionieren prinzipiell gut, sind allerdings nicht für den Dauerbetrieb als Access Point gedacht und verhalten sich in dieser Betriebsart recht instabil.

# opkg install htop mc nano vim ncdu tcpdump tshark watchcat
# opkg install luci luci-app-firewall luci-app-opkg luci-app-watchcat luci-base luci-compat luci-lib-base luci-lib-ip luci-lib-jsonc
# opkg install luci-lib-nixio luci-mod-admin-full luci-mod-network luci-mod-status luci-mod-system luci-proto-ipv6 luci-proto-ppp luci-theme-bootstrap
# opkg install findutils-locate
# opkg install findutils-find findutils findutils-xargs findutils-locate rsync
# opkg install kmod-mt76-usb kmod-mt76x02-usb kmod-usb-core kmod-usb-ledtrig-usbport kmod-usb3 libusb-1.0-0 usb-modeswitch usbreset usbutils

Verwenden Sie mehrere Geräte als Mesh, Access Point oder Repeater, bietet es sich an, auf einem Steuerrechner Cluster SSH [14] oder CSSH [15] zu installieren und für die Administration zu verwenden, um zentral alle Geräte zeitgleich mit Updates zu versorgen.

Fazit

OpenWrt erweist sich als sehr mächtiges Werkzeug für alle Probleme rund um WLANs. Die Administration ist allerdings an einigen Punkten etwas eigenwillig und für Einsteiger nicht unbedingt in sich schlüssig. Das OpenWrt-Forum präsentiert sich einerseits als wahre Goldgrube für Informationen, andererseits aber auch als unübersichtliches Labyrinth mit vielen völlig veralteten toten Ecken. Die hier vorgestellten Kniffe, Konfigurationsergänzungen und Tools erlauben ein standardisiertes Management über alle verschiedenen Hardwareplattformen, sofern man grundsätzlich mit Linux-Systemen vertraut ist. (jcb/jlu)