Projekt: Multi-LTE-Anbindung “Kippstell” Netzwerkparty

Für die Netzwerkparty in der Kippstelle (Dortmund-Eving) wird eine gebündelte Internetanbindung über mehrere LTE-Verbindungen realisiert. Basis ist OpenMPTCProuter, das mittels MPTCP mehrere LTE-Uplinks zu einer stabilen, schnelleren Verbindung bündelt.

Rahmen

Die Netzwerkparty läuft eine Woche mit ca. 15 Teilnehmern. LTE-Verbindungen werden dort bereits seit mehreren Jahren eingesetzt.

Aufbau

• Serverseitig: VPS mit fester IP, bereitgestellt von Freifunk Dortmund
• Vor Ort: Ubiquiti EdgeRouter X (ER-X) (5 Ports) mit OpenMPTCProuter
• Zusätzlich: Freifunk-Router für Gäste-WLAN

LTE-Anbindungen

3 von 4 möglichen Slots belegt, ein Port/Slot ist noch frei.

Ziel

Zuverlässiges, gebündeltes Internet für die Veranstaltung ohne Abhängigkeit von einer einzelnen Mobilfunkverbindung.

Gefahrenbewertung

• Datenvolumen: Erfahrungswert liegt unter 400 GB pro Woche (u.a. durchgängiges YouTube auf dem Beamer für Musikvideos) – bei kombiniertem Kontingent von 220 GB (Vodafone+Telekom) plus o2-Flatrate bisher unkritisch
• Single Point of Failure: Fällt der ER-X aus, sind alle Teilnehmer offline (keine redundante Router-Hardware vor Ort)
• Physische Sicherheit: Gering kritisch, da geschlossene Gruppe von ca. 15 sich seit Jahren bekannten Personen im selben Raum
• Hardware-Stabilität ER-X: Alpha-Support laut Hersteller. Dokumentierter Bug-Report (2021, ungelöst) zeigt Abstürze bei Mehrfach-WAN-Betrieb (Portflapping oder Reboot). Kein aktueller Fix bekannt.
• Netzwerksicherheit: MPTCP-Tunnel zum Freifunk-Server als zentraler Vertrauensanker; kein Fremdzugriff durch Externe zu erwarten. Zusätzlich wird ein lokaler Freifunk-Router für Gäste und das nähere Umfeld aufgestellt – freies Internet ohne Anmeldung.

Freifunk Dortmund

Freifunk Dortmund ist ein ehrenamtliches Community-Projekt, das freies, offenes WLAN ohne Anmeldung für alle bereitstellt. Genau ein solcher Freifunk-Router wird auf der Netzwerkparty für Gäste betrieben und erweitert so das lokale Mesh-Netz. Wer mitmachen möchte, kann eigene Router betreiben und so das Netz ausbauen. Mehr Infos unter freifunk-dortmund.de.

Server-Setup: Debian-13-Problematik

Der Test-VPS (marcel.ffdo.net, ehem. Matrix-Testserver) läuft auf Debian 13 (Trixie). Das offizielle OMR-Server-Script (debian-x86_64.sh) unterstützt explizit nur Debian 9–12; bei Debian 13 bricht es mit klarer Fehlermeldung ab (“This script only work with Debian Stretch (9.x)… or Debian Bookworm (12.x)”).

Debian 13 ist so neu (Release 2025), dass viele Softwareprojekte ihre Kompatibilitätsprüfungen noch nicht aktualisiert haben – Paketnamen, Abhängigkeiten und Kernel-Module können sich zwischen Debian-Versionen ändern, weshalb Scripts wie das von OMR oft nur explizit getestete/freigegebene Versionen erlauben. Bei OMR kommt hinzu, dass es stark auf systemd-Dienste, feste Paketversionen und teils selbst kompilierte Kernel-Module setzt – das macht das Projekt empfindlicher gegenüber Distributions-Updates als einfachere Software.

Workaround-Versuch: Docker-Container mit Debian 12 Da der Server unter KVM (eigener Kernel, nicht LXC) läuft, wurde versucht, das Script in einem Docker-Container mit debian:12-Image auszuführen (--privileged --network host), um die Versionsprüfung zu umgehen und dabei den bereits MPTCP-fähigen Host-Kernel (6.12) mitzunutzen.

• Grundinstallation (Pakete, Zertifikate, Webinterface-Setup) lief großteils durch
• Kritische Einschränkung: Docker-Container laufen standardmäßig ohne systemd als PID 1 – dienste-basierte Prüfung/Verwaltung (systemctl status ...) schlägt fehl (“System has not been booted with systemd as init system”). Zentrale Komponenten wie shadowsocks-libev und glorytun wurden dadurch nicht wie erwartet eingerichtet
• Fazit: Docker ist für dieses systemd-lastige Server-Setup keine zuverlässige Lösung, auch wenn die reine Paketinstallation grundsätzlich möglich wäre

Zusätzlich gefundener Script-Bug (unabhängig von Debian 13): Bei KERNEL≠"5.4" wird die Variable SOURCES im Script zwangsweise auf "yes" gesetzt (Zeilen 44–46), auch wenn man SOURCES="no" explizit übergibt. Das löst einen fehlerhaften iperf3-Build-Pfad aus: Das Script versucht iperf3_3.18-1.debian.tar.xz von deb.debian.org zu laden, das dort nicht mehr existiert (nur 3.12-1+deb12u2 verfügbar) → 404-Fehler, Installation bricht ab. Workaround: Zeile 568 im lokal heruntergeladenen Script patchen, um den Source-Build-Zweig zu überspringen (nutzt dann apt-get install iperf3 direkt).

Nächster Schritt: Test auf echtem Debian-12-VPS (z. B. Hetzner CX22, ca. €4/Monat) ohne Docker-Umweg, um zu prüfen, ob die Installation dort sauber und vollständig durchläuft.

Ergebnis-Meldung an Upstream: Der iperf3/SOURCES-Bug soll als Issue im Repo openmptcprouter-vps gemeldet werden, sobald das Setup steht.

OpenMPTCProuter (OMR) auf dem migrierten ER-X: Fehleranalyse

Nach der Migration auf OpenWrt 24.10.1 (Kernel 6.6.86) wurde versucht, das offizielle OMR-Image für den ER-X aufzuspielen (openmptcprouter-v0.64.2-6.18-...-ubnt_edgerouter-x-squashfs-sysupgrade.bin). Der Flash-Vorgang selbst lief erfolgreich durch (passendes Partitionslayout dank vorheriger Migration). Danach zeigten sich mehrere, im Detail dokumentierte Probleme:

1. Kein vollständiges LuCI vorinstalliert

Nach dem Flash war unter http://192.168.100.1 (Standard-OMR-Zugriff über den WAN-Port, nicht LAN) keine Weboberfläche erreichbar. Ursache: uhttpd war im Image nicht installiert.

Schrittweise Nachinstallation über apk nötig, bis die Oberfläche lief:

apk add luci-base uhttpd uhttpd-mod-ubus
apk add luci-theme-bootstrap
apk add luci-mod-admin-full
rm -f /tmp/luci-indexcache
/etc/init.d/uhttpd restart

Jedes fehlende Teilstück äußerte sich als eigener Fehler (u. a. „Unable to render any theme header template“, „No page is registered at ‘/’“), bis alle vier Pakete installiert waren.

Ergebnis: Standard-OpenWrt-LuCI (System, Netzwerk, etc.) war danach nutzbar – aber ohne jeden OMR-spezifischen Bedienbereich.

2. OMR-eigener Paket-Feed liefert 404 / fehlt komplett

Die für den OMR-Wizard und die Kernfunktionen nötigen Pakete (luci-app-openmptcprouter, glorytun-tcp, shadowsocks-libev u. a.) liegen in einem eigenen Feed (openmptcprouter), der bei diesem Kernel-Build (6.6, v0.64.2-6.18) nicht erreichbar ist:

apk search -v 'glorytun*'
WARNING: opening from cache http://download.openmptcprouter.com:80/release/v0.64.2-6.18/ubnt-erx/packages/mipsel_24kc/openmptcprouter/packages.adb: No such file or directory

Getestet wurden zwei unterschiedliche, im System hinterlegte Feed-URLs (download.openmptcprouter.com und packages.openmptcprouter.com) – beide liefern für den openmptcprouter- und luci-Feed einen 404-Fehler.

Dies ist ein bekannter, offener Bug im Projekt selbst, dokumentiert in Issue #3176 (“opkg not updated lists on latest 6.6 kernel OMR”), betrifft alle Geräte/Architekturen mit dem neueren 6.6-Kernel-Build, nicht nur den ER-X.

Konsequenz: Weder das LuCI-Wizard-Paket noch die eigentlichen Bonding-Kernkomponenten (Glorytun, Shadowsocks) lassen sich auf diesem Image regulär installieren. Das Problem liegt auf Seite des OMR-Projekts (kaputte/nicht gepflegte Paketquelle), nicht an unserer Konfiguration.

Fazit zu OMR auf dem ER-X

Nach mehreren Etappen (Debian-13-Sperre umgangen, iperf3-Bug gepatcht, glorytun-Build-Bug gepatcht, ER-X-Partitionsmigration durchgeführt) hat sich gezeigt, dass der aktuelle OMR-Release-Zweig (v0.64.2, Kernel 6.6/6.18) an mehreren, voneinander unabhängigen Stellen fehlerhaft bzw. unvollständig gepflegt ist. Eine funktionierende OMR-Installation auf dem ER-X ist mit aktuellem Stand nicht ohne eigenen Paket-Build erreichbar.

Kurswechsel: BondingShouldBeFree (BSBF) statt OMR

Als Alternative zu OMR wurde BondingShouldBeFree (BSBF) identifiziert, ein aktiveres, schlankeres Projekt mit demselben Ziel (MPTCP-basiertes Verbindungs-Bonding):

• Nutzt den Mainline-Linux-MPTCP-Stack (bereits im OpenWrt-24.10-Kernel enthalten, kein Custom-Kernel nötig)
• Nutzt xray-core (VLESS-Protokoll) statt Glorytun/Shadowsocks
• Bietet einen Firmware-Selector (fs.bondingshouldbefree.org), der über OpenWrts offiziellen Attended-Sysupgrade-Dienst ein fertiges, vorkonfiguriertes Client-Image baut
• Server-Installer läuft auf gewöhnlichen Linux-Distributionen mit apt, systemd und ifupdown (keine dokumentierte Einschränkung auf bestimmte Debian-Versionen, im Unterschied zu OMR)

Stand: Wird aktuell evaluiert, noch nicht produktiv getestet. Nächste Schritte: Server-Installer-Script sichten und auf dem Freifunk-Server testen, danach Client-Image über den Firmware-Selector für den ER-X bauen.