Das Problem mit dem Ubiquiti EdgeRouter X (-SFP)
Wir migrieren gerade unsere Freifunk-Knoten auf die neue Firmware 1.5.0. Klingt nach einem normalen Update-Zyklus – ist es aber nicht immer. Beim Ubiquiti EdgeRouter X (und ERX-SFP) haben wir uns in der Vergangenheit schon einmal die Finger dran verbrannt, weshalb es zunächst eine manuelle Migration brauchte. Das Vorgehen und der Hintergrund stehen hier:
Die gute Nachricht zuerst: Das ist mittlerweile Geschichte. 🎉
Wir können unsere ERX-Knoten inzwischen automatisiert migrieren. Die weniger gute Nachricht: Auf dem Weg dahin haben wir zwei sehr lehrreiche (und sehr reale) Stolperfallen gefunden – beide im Wattenscheider Ferienlager in Mellnau.
Die neue Automations-Migration: Firmware-Hopping mit Netz und doppeltem Boden
Damit die Migration zuverlässig und ohne Vor-Ort-Einsatz klappt, bootet ein Knoten jetzt bewusst über mehrere Zwischenstände:
Update: 1.2.0 → 1.4.99-MIG-01
(Konfiguration auf Server pushen & Flash-Layout automatisiert migrieren als Vorbereitung auf 1.4.99-MIG-02)
Update: 1.4.99-MIG-01 → 1.4.99-MIG-02
(Konfiguration von Server herunterladen)
Update: 1.4.99-MIG-02 → 1.4.7
Update: 1.4.7 → 1.5.0
Das Herzstück (und gleichzeitig die heikle Stelle) ist zwischen den Firmwares 1.4.99-MIG-01 und 1.4.99-MIG-02:
Nach diesem Schritt startet der Knoten mit einer Standardkonfiguration – ohne Hostname, ohne SSH-Keys, ohne unsere gewohnte Freifunk-spezifische Konfig. In genau diesem Zustand wird dann die Knoten-Konfiguration vom Server geladen und zurückgespielt.
Das ist technisch notwendig, aber eben auch: komplex. Und alles, was komplex ist, findet Wege, kaputtzugehen.
Port-Design: Warum eth0 = WAN und eth1–eth4 = Mesh on LAN?
Unsere Port-Rollen sind in der Firmware 1.4.99-MIG-02 bewusst so gesetzt:
- eth0 = WAN
- eth1–eth4 = Mesh on LAN
Der Grund: Wir wollen, dass Knoten, die am WAN eine eigene Anbindung haben, zuverlässig eine Verbindung zum Gateway aufbauen können. Gleichzeitig sollen ERXe ohne eigene WAN-Anbindung ihren Uplink per Mesh von benachbarten Knoten erhalten.
Das sieht auf den ersten Blick solide aus. Aber in einer Migrations-Firmware, die mit Minimal-Defaults bootet, wird aus „solide“ schnell „tückisch“.
Problem 1: Mesh-Uplink am falschen Port (Mellnau-Ferienlager-ERX3)
Beim Mellnau-Ferienlager-ERX3 hatten wir die folgende Situation:
- kein WAN-Uplink vorhanden
- Mesh-Uplink vorhanden
- dieser Mesh-Uplink kam allerdings physisch an eth0 an
Und jetzt kommt der Knackpunkt:
In 1.4.99-MIG-02 macht die Default-Konfiguration an eth0 ausschließlich WAN.
Ergebnis: Auf eth0 war plötzlich kein “Mesh on LAN” mehr möglich, sondern nur noch das, was der Knoten als WAN/VPN-Logik interpretiert. Damit war der Router aus Sicht des Freifunk-Netzes offline. Er konnte sich seine Konfiguration nicht mehr herunterladen.
Kurz gesagt: Der Uplink war da, aber die Rolle des Ports war falsch.
Und bei Freifunk ist „falsche Rolle“ oft gleichbedeutend mit „Knoten offline“.
Problem 2: Der ERX-SFP sägt sich selbst ab (Mellnau-Ferienlager-ERX2)
Der zweite Fall war noch fieser, weil er wie ein klassischer „Warum bleiben die Geräte offline?!“-Moment wirkt.
Der EdgeRouter X SFP unterscheidet sich nicht nur durch den SFP-Slot, sondern auch dadurch, dass er auf allen RJ45-Ports 24V Passiv PoE ausgeben kann. Wir nutzen das ganz bewusst:
- Richtfunk-Antennen direkt vom Router versorgen
- PoE per Software steuerbar → Geräte remote neustarten (Luxus!)
Und genau dieser Luxus hat uns bei 1.4.99-MIG-02 reingelegt:
Beim Boot in der Firmware 1.4.99-MIG-02 sind die PoE-Ausgänge standardmäßig deaktiviert – als Schutzmaßnahme, damit man nicht aus Versehen Endgeräte grillt. Total logisch und sicher, aber in dem Setup des Wattenscheider Ferienlager fatal.
Denn: Wenn PoE aus ist, sind die Antennen aus.
Wenn die Antennen aus sind, ist der Uplink aus.
Wenn der Uplink aus ist, kann der ERX-SFP keine Konfiguration vom Server beziehen.
Wenn er keine Konfiguration beziehen kann, bleibt PoE aus.
Das ist eine besonders hübsche Falle aus der Kategorie:
„Remote-Management ist toll, bis das Remote-Management die Leitung kappt, die du fürs Remote-Management brauchst.“
Der Mellnau-Ferienlager-ERX2 hat sich also seinen eigenen Ast abgesägt und nebenbei alles dahinter mit in die Dunkelheit genommen.
Incident-Response à la Freifunk: Improvisation gewinnt (Andi auf dem Sportplatz)
Um das zu lösen, brauchten wir keine große Theorie – sondern Andi, einen mit Freifunk vernetzten Sportplatz und genug Netzwerk-Technik, um einen kleinen Sci-Fi-Film zu drehen.
Andi ist (spätabends) zum Sportplatz gefahren (der vom Ferienlager mit dem Freifunk-Netz versorgt wird) und hat mit folgendem Setup eine temporäre Anbindung gebaut:
- TP-Link Archer C7
- GL.iNet Travel Router
- USB Powerbank
- USB-Tethering vom iPhone
Damit hatte der Sportplatz wieder kurzzeitig Freifunk-Anbindung – und wir haben somit das Netz so umgebaut, dass es den ERX-SFP wieder „hochzieht“, ohne ans Ferienlager selbst zu müssen.
Das Mesh-Manöver: Den Versorger über die Versorgten versorgen
Weil der ERX-SFP (Mellnau-Ferienlager-ERX2) ohne Uplink seine Konfiguration nicht laden konnte, mussten wir ihm den Uplink anders herum geben: über die Knoten, die er eigentlich versorgen sollte.
Die Verkettung sah dann so aus:
Wetter-Reserve184 (Archer C7)
→WLAN-Mesh→
Mellnau-Sportplatz (UniFi AC-PRO)
→Kabel-Mesh→
Mellnau-Sportplatz-ERX
→Richtfunk-Mesh→
Mellnau-Ferienlager-ERX3
→Kabel-Mesh→
Mellnau-Ferienlager-ERX2 (PoE aus, daher eigentlicher Fehlerpunkt)
→Richtfunk-Mesh→
Mellnau-Wagenhaeuser-ERX
Damit haben wir es geschafft, dass der Mellnau-Ferienlager-ERX2 wieder „Netz sieht“, seine Konfiguration vom Server bezieht, die PoE-Ports wieder aktiviert – und er anschließend sauber weiterupgradet:
1.4.99-MIG-02 → 1.4.7 → 1.5.0
Und das Beste: Volle Entstörung ohne Zugang zum Wattenscheider Ferienlager.
Lessons Learned
- Migration-Firmwares sind nicht „nur Updates“.
Sobald ein Knoten mit Default-Konfiguration startet, gelten die Annahmen über Ports, Services, Keys und Identität erst mal gar nicht. Das kann unter besonderen Umständen zum Problem werden. - Portrollen müssen zu realen Uplink-Pfaden passen
„eth0 ist WAN“ ist eine sinnvolle Konvention – bis Mesh-Uplink physisch auf eth0 ankommt. Dann ist das kein Konfig-Detail mehr, sondern ein echter Ausfallgrund. - PoE-Defaults sind Sicherheitsfeatures – und können trotzdem Netz killen
Beim ERX-SFP ist „PoE standardmäßig aus“ sinnvoll, aber in Installationen, wo PoE Teil des Uplinks ist, wird daraus ein massives Problem: ohne Uplink keine Konfiguration, ohne Konfiguration kein PoE, ohne PoE kein Uplink. - Mesh ist nicht nur Redundanz – es kann auch ein Rettungsweg sein
Dass wir den Router über die Infrastruktur „von hinten“ wieder ins Netz holen konnten, ist genau der Moment, wo Mesh seine Superkraft zeigt.
Fazit
Der EdgeRouter X (und besonders der ERX-SFP) ist im Freifunk-Kontext ein kleines Arbeitstier – aber Migrationen legen gnadenlos offen, wo implizite Annahmen stecken: Portrollen, PoE-Abhängigkeiten, Uplink-Topologien.
Am Ende haben wir die Situation ohne Vor-Ort-Zugang am eigentlichen Standort gelöst, die betroffenen Knoten auf 1.5.0 gebracht und nebenbei ein paar neue graue Haare verdient.
Ein Hoch auf das Mesh – und riesigen Dank an Andi fürs Retten der Lage!
