wiki/Technik/Routing/openmptcp/openmptcprouter.page

# 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.