# 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](https://github.com/ysurac/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)](https://openwrt.org/toh/ubiquiti/edgerouter_x_er-x_ka) (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. | Gerät | Provider | Datenvolumen | |---|---|---| | Fritzbox LTE | o2 | Flatrate | | Fritzbox LTE | Vodafone | 100 GB | | TP-Link LTE | Telekom | 120 GB | ## 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](https://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](https://github.com/Ysurac/openmptcprouter-vps/issues) 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](https://github.com/Ysurac/openmptcprouter/issues/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)](https://github.com/bondingshouldbefree) 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.