Domů Procházet Nápověda
Přihlásit se
ffdo
/
wiki
2
0
Rozštěpit 0
Soubory Úkoly 0 Pull Requesty 0 Wiki
Strom: f900feb5ab
Větve Značky
wiki
/
Technik
/
Routing
/
openmptcp
/
openmptcprouter.page

openmptcprouter.page 9.2 KB
Historie Surový

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111 
  1. # Projekt: Multi-LTE-Anbindung "Kippstell" Netzwerkparty
    2. 

  2. 

  3. 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.
    4. 

  4. 

  5. ## Rahmen
    6. 

  6. 

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

  8. 

  9. ## Aufbau
    10. 

  10. 

  11. - Serverseitig: VPS mit fester IP, bereitgestellt von Freifunk Dortmund
    12. 

  12. - Vor Ort: [Ubiquiti EdgeRouter X (ER-X)](https://openwrt.org/toh/ubiquiti/edgerouter_x_er-x_ka) (5 Ports) mit OpenMPTCProuter
    13. 

  13. - Zusätzlich: Freifunk-Router für Gäste-WLAN
    14. 

  14. 

  15. ## LTE-Anbindungen
    16. 

  16. 

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

  18. 

  19. | Gerät | Provider | Datenvolumen |
    20. 

  20. |---|---|---|
    21. 

  21. | Fritzbox LTE | o2 | Flatrate |
    22. 

  22. | Fritzbox LTE | Vodafone | 100 GB |
    23. 

  23. | TP-Link LTE | Telekom | 120 GB |
    24. 

  24. 

  25. ## Ziel
    26. 

  26. 

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

  28. 

  29. ## Gefahrenbewertung
    30. 

  30. 

  31. - **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
    32. 

  32. - **Single Point of Failure:** Fällt der ER-X aus, sind alle Teilnehmer offline (keine redundante Router-Hardware vor Ort)
    33. 

  33. - **Physische Sicherheit:** Gering kritisch, da geschlossene Gruppe von ca. 15 sich seit Jahren bekannten Personen im selben Raum
    34. 

  34. - **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.
    35. 

  35. - **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.
    36. 

  36. 

  37. ### Freifunk Dortmund
    38. 

  38. 

  39. 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).
    40. 

  40. 

  41. ## Server-Setup: Debian-13-Problematik
    42. 

  42. 

  43. 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)").
    44. 

  44. 

  45. 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.
    46. 

  46. 

  47. **Workaround-Versuch: Docker-Container mit Debian 12**
    48. 

  48. 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.
    49. 

  49. 

  50. - Grundinstallation (Pakete, Zertifikate, Webinterface-Setup) lief großteils durch
    51. 

  51. - **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
    52. 

  52. - **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
    53. 

  53. 

  54. **Zusätzlich gefundener Script-Bug (unabhängig von Debian 13):**
    55. 

  55. 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.
    56. 

  56. *Workaround:* Zeile 568 im lokal heruntergeladenen Script patchen, um den Source-Build-Zweig zu überspringen (nutzt dann `apt-get install iperf3` direkt).
    57. 

  57. 

  58. **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.
    59. 

  59. 

  60. **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.
    61. 

  61. 

  62. 

  63. # OpenMPTCProuter (OMR) auf dem migrierten ER-X: Fehleranalyse
    64. 

  64. 

  65. 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:
    66. 

  66. 

  67. ### 1. Kein vollständiges LuCI vorinstalliert
    68. 

  68. 

  69. 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.
    70. 

  70. 

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

  72. ```
    73. 

  73. apk add luci-base uhttpd uhttpd-mod-ubus
    74. 

  74. apk add luci-theme-bootstrap
    75. 

  75. apk add luci-mod-admin-full
    76. 

  76. rm -f /tmp/luci-indexcache
    77. 

  77. /etc/init.d/uhttpd restart
    78. 

  78. ```
    79. 

  79. 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.
    80. 

  80. 

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

  82. 

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

  84. 

  85. 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:
    86. 

  86. 

  87. ```
    88. 

  88. apk search -v 'glorytun*'
    89. 

  89. 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
    90. 

  90. ```
    91. 

  91. 

  92. 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.
    93. 

  93. 

  94. **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.
    95. 

  95. 

  96. **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.
    97. 

  97. 

  98. ### Fazit zu OMR auf dem ER-X
    99. 

  99. 

  100. 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.
    101. 

  101. 

  102. ## Kurswechsel: BondingShouldBeFree (BSBF) statt OMR
    103. 

  103. 

  104. Als Alternative zu OMR wurde [BondingShouldBeFree (BSBF)](https://github.com/bondingshouldbefree) identifiziert, ein aktiveres, schlankeres Projekt mit demselben Ziel (MPTCP-basiertes Verbindungs-Bonding):
    105. 

  105. 

  106. - Nutzt den **Mainline-Linux-MPTCP-Stack** (bereits im OpenWrt-24.10-Kernel enthalten, kein Custom-Kernel nötig)
    107. 

  107. - Nutzt **xray-core** (VLESS-Protokoll) statt Glorytun/Shadowsocks
    108. 

  108. - Bietet einen **Firmware-Selector** (`fs.bondingshouldbefree.org`), der über OpenWrts offiziellen Attended-Sysupgrade-Dienst ein fertiges, vorkonfiguriertes Client-Image baut
    109. 

  109. - 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)
    110. 

  110. 

  111. **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.
    112.