wiki/Technik/Routing/openmptcp/EdgeRouter.page

# Anleitung: Ubiquiti EdgeRouter X (ER-X) auf aktuelles OpenWrt migrieren

## Ausgangslage

Der ER-X hat eine sehr kleine, fest reservierte Kernel-Partition (3 MB). Ältere OpenWrt-Versionen (z. B. 22.03.x) passen noch rein, neuere Kernel (6.6+, ab OpenWrt 23.05/24.10) nicht mehr ohne Änderung der Partitionstabelle.

Ein normales Sysupgrade/Firmware-Update über die Web-Oberfläche schlägt daher mit folgendem Fehler fehl:

```
upgrade: The device is supported, but this image is incompatible for sysupgrade based on the image version (1.1->2.0).
upgrade: Partition table has been changed due to kernel size restrictions.
Image check failed.
```

Das ist normal und kein Zeichen eines defekten Geräts – es braucht einen einmaligen Migrationsschritt.

## Voraussetzung

- ER-X läuft bereits mit Standard-OpenWrt (nicht mehr originaler Ubiquiti EdgeOS-Firmware)
- SSH-Zugriff auf den Router
- **Wichtig:** Die Migration setzt das Gerät komplett zurück (alle Einstellungen gehen verloren). Vorher Konfiguration sichern, falls benötigt (Backup über LuCI: System → Backup/Flash Firmware → "Generate archive")

## Ablauf

### 1. Mit dem Router verbinden

```
ssh root@<router-ip>
```
(Standard-IP bei Werkszustand meist `192.168.1.1`, kann je nach bisheriger Konfiguration abweichen)

### 2. Migrations-Scripts laden

Auf dem Router:
```
cd /tmp
wget --no-check-certificate https://raw.githubusercontent.com/darkxst/erx-migration/refs/heads/main/ubnt_erx_migrate.sh
wget --no-check-certificate https://raw.githubusercontent.com/darkxst/erx-migration/refs/heads/main/ubnt_erx_stage2.sh
chmod +x ubnt_erx_migrate.sh
```

Zur Kontrolle prüfen, dass beide Dateien echte Scripts sind (mehrere KB groß, keine HTML-Fehlerseite):
```
ls -la ubnt_erx_migrate.sh ubnt_erx_stage2.sh
```

### 3. Migration starten

```
./ubnt_erx_migrate.sh
```

Das Script fragt nach Bestätigung (`y`/`n`) und weist nochmal auf den Datenverlust hin. Nach Bestätigung:
- Lädt automatisch das aktuelle OpenWrt-Release (zum Zeitpunkt dieser Anleitung: 24.10.1) für den ER-X
- Führt die Neupartitionierung durch
- Gerät startet neu – **SSH-Verbindung bricht dabei ab, das ist normal**

### 4. Warten und neu verbinden

Nach dem Neustart (ca. 2–3 Minuten) hat der Router in der Regel wieder die Standard-IP `192.168.1.1` (auch wenn vorher eine andere IP konfiguriert war).

```
ping 192.168.1.1
```

Sobald erreichbar:
```
ssh root@192.168.1.1
```

**Hinweis:** Der SSH-Host-Key hat sich geändert (neue Installation), daher erscheint eine Sicherheitswarnung. Das ist normal, kein Angriff. Alten Eintrag entfernen:
```
ssh-keygen -f '~/.ssh/known_hosts' -R '192.168.1.1'
```
Danach erneut verbinden.

### 5. Fertig – Grundabsicherung

Nach erfolgreichem Login zeigt sich die neue Version, z. B.:
```
OpenWrt 24.10.1, r28597-0425664679
```

Root-Passwort setzen (Pflicht, da initial keins gesetzt ist):
```
passwd
```

Kontrolle, dass das neue Partitionslayout aktiv ist:
```
grep compat_version /etc/config/system
```
(sollte `2.0` zeigen)

## Ergebnis

Der Router läuft jetzt auf aktuellem OpenWrt mit modernem Kernel und neuer Partitionstabelle. Zukünftige Sysupgrades auf neuere OpenWrt-Versionen funktionieren ab hier wieder normal über die Web-Oberfläche oder `sysupgrade`, ohne erneute Migration.

## Quelle

Migrations-Scripts von [darkxst/erx-migration](https://github.com/darkxst/erx-migration), siehe auch [OpenWrt-Forum-Thread "Resizing kernel images for Edgerouter X"](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968).

## Erfahrung aus unserem Test

Migration wurde am 26.09.2026 an einem Ersatz-ER-X erfolgreich getestet (von OpenWrt 22.03.5 auf 24.10.1). Ablauf lief ohne Komplikationen durch, Downloads und Neustart wie beschrieben.

---

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