Files

Christoph Emsenhuber b93514a045 RouterBOOT-Klickanleitung + TP5 E3/E4 abgenommen, NTP-Zeitquelle, Template-Fixes

docs/routerboot-firmware-klickanleitung.md: Schritt-fuer-Schritt fuer WinBox.
RouterOS ist auf allen vier bereits 7.24, nur der Bootloader haengt zurueck
(core/branch 7.19.5, ap1/ap2 7.23.2 -- live erhoben). Der Weg geht per Hand,
weil `/system routerboard upgrade` interaktiv nachfragt: MikroMCP blockt ihn per
Deny-Policy, und Netmiko bekommt den Prompt statt einer Antwort und quittiert mit
E3001 bei LEERER Fehlermeldung. Auf core/branch waere ein Scheduler-Umweg
moeglich, auf den APs nicht (device-mode=home sperrt ihn).
Reihenfolge ap1 -> ap2 -> core -> branch mit Ausfall je Geraet; branch zuletzt,
weil der Arbeitsplatz per Kabel daran haengt. Dazu Gegenprobe-Einzeiler fuer alle
vier und die Falle, dass ohne Schritt 7 (Reboot) `Current Firmware` alt bleibt.

Aus der Parallelsession dazugekommen:
- TP5 Etappe 3 UND 4 sind abgenommen, beide Auto-Reverts abbestellt. Die
  Abnahmen stehen in den Skriptkoepfen: forward-Drop hat in der Testphase 11
  Pakete gefressen, ausschliesslich die eigene pve->branch:22-Sonde; beim
  input-Drop war es reines Broadcast-Rauschen (NetBIOS, SSDP). Der GC-Deploy-Pfad
  wurde als Pfadbeweis mitgetestet (nautobot-worker -> ap2:22 = SUCCESS).
- E4-Nachtrag: MNDP und CAPWAP muessen in den input. Die CAPs finden ihren
  Manager per Layer-2-Discovery (`current-caps-man-address` ist eine MAC, keine
  IP) -- bestehende Sitzungen laufen ueber seal-est weiter, der Bruch schluege
  also erst beim naechsten AP- oder Manager-Neustart zu.
- TP19 NTP: alle drei Nicht-Core-Geraete fragten einen Zeitserver, den es nicht
  gab (`status=waiting`, branch hatte gar keinen). ap2 war 17 Stunden nach und
  hat einen Logeintrag von 04:57 als 12:19 gestempelt -- geraeteuebergreifende
  Korrelation war damit wertlos. Core wird Zeitquelle, die drei werden Clients.
- Template: `/ip service` exportiert `available-from=`, nicht `address=`. Das
  Soll war falsch und das Geraet hatte recht -- vier Dauer-Drifts. Und
  `hw-offload` fliegt aus dem Firewall-Renderer, weil REST es meldet und
  /export es weglaesst.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-18 05:15:28 +02:00

4.9 KiB

Raw Blame History

RouterBOOT-Firmware auf 7.24 nachziehen — Klickanleitung (WinBox)

Stand 2026-08-18, live erhoben. RouterOS ist auf allen vier Geräten bereits 7.24. Zurück hängt nur der Bootloader (RouterBOOT):

Gerät	IP	Modell	aktuell	Ziel
`crs326-core`	10.40.99.1	CRS326-24G-2S+	7.19.5	7.24
`crs326-branch`	10.40.99.2	CRS326-24G-2S+	7.19.5	7.24
`ap1`	10.40.99.11	hAP ax²	7.23.2	7.24
`ap2`	10.40.99.12	hAP ax²	7.23.2	7.24

Warum das per Hand geht und nicht über die Automatik

/system routerboard upgrade fragt interaktiv nach („Do you really want to upgrade firmware?"). Damit fällt es durch beide Wege raus, die dieses Netz sonst nutzt:

MikroMCP blockt den Befehl per Deny-Policy (er schreibt den Bootloader).
Nautobot Golden Config schickt die Zeile per Netmiko ab, bekommt den Prompt statt einer Antwort und quittiert mit E3001 und leerer Fehlermeldung. Am 2026-08-17 genau so passiert — es wurde nichts geschrieben, aber auch nichts gemeldet.

Auf core und branch ginge ein Umweg über den Scheduler (dort läuft kein device-mode=home). Auf ap1/ap2 nicht — dort ist der Scheduler gesperrt. Für vier Geräte ist der Klickweg schlicht der ehrlichere.

Die Klicks (identisch auf jedem Gerät)

WinBox öffnen → Reiter Neighbors → Gerät in der Liste doppelklicken (oder unter Connect To die IP aus der Tabelle oben eintippen). Login admin, Passwort aus ~/.secrets (auf allen vier gleich).
Links im Menü System → RouterBOARD.
Im Fenster stehen zwei Zeilen:
- Current Firmware: 7.19.5 (bzw. 7.23.2)
- Upgrade Firmware: 7.24 ➡️ Stehen beide auf 7.24, ist das Gerät fertig — Fenster zu, nächstes Gerät.
Oben auf den Knopf Upgrade klicken.
Rückfrage „Do you really want to upgrade firmware?" → Yes.
Es erscheint sinngemäß „Firmware upgraded, reboot for changes to take effect". Die Firmware ist damit geschrieben, aber noch nicht aktiv.
Links im Menü System → Reboot → Yes.
Warten (CRS326 ~40 s, hAP ~60 s), neu verbinden, System → RouterBOARD öffnen: Current Firmware muss jetzt 7.24 sein.

Schritt 7 nicht vergessen. Ohne Reboot bleibt Current Firmware auf dem alten Wert, und beim nächsten Blick sieht es aus, als hätte der Upgrade nicht funktioniert.

Reihenfolge — und was dabei jeweils ausfällt

Von harmlos nach heikel. Jedes Gerät erst abschließen (inkl. Reboot und Gegenprobe), bevor das nächste drankommt.

#	Gerät	Was während des Reboots weg ist	Dauer
1	ap1	WLAN im UG. Clients wechseln auf ap2, Roaming fängt das ab.	~60 s
2	ap2	WLAN im OG, dazu kurz die Shellys. Sie kommen von selbst zurück.	~60 s
3	crs326-core	⚠️ Alles: Routing, DHCP, DNS, Internet, WireGuard, CAPsMAN-Manager.	~40 s
4	crs326-branch	⚠️ Deine LAN-Verbindung (dein Arbeitsplatz hängt daran) + NAS/Drucker/macmini.	~40 s

branch bewusst zuletzt: dein Rechner hängt per Kabel daran. Wenn dabei etwas schiefgeht, sind alle anderen Geräte schon nachweislich oben — und der Fehler ist damit eingegrenzt.

Beim Core: WLAN und LAN laufen weiter (die APs sind CAPs und behalten ihre Konfiguration, die Switches schalten Layer 2 unabhängig), aber es gibt für die Dauer des Reboots kein DHCP, kein DNS und kein Internet. Kein guter Moment für ein Telefonat.

Gegenprobe hinterher (statt Klicken)

Alle vier auf einmal, ohne WinBox:

cd ~/dev/bf-network-r6 && for s in "core:10.40.99.1:CRS326_CORE_PASS" "branch:10.40.99.2:CRS326_BRANCH_PASS" "ap1:10.40.99.11:ROUTER_AP1_PASS" "ap2:10.40.99.12:ROUTER_AP2_PASS"; do n=${s%%:*}; r=${s#*:}; ip=${r%%:*}; v=${r##*:}; p=$(grep -E "^(export )?$v=" ~/.secrets/credentials.env | head -1 | sed -E "s/^(export )?$v=//" | tr -d "\"'"); curl -s -u "admin:$p" --max-time 8 "http://$ip/rest/system/routerboard" | python3 -c "import json,sys;d=json.load(sys.stdin);print(f'  $n  current={d.get(\"current-firmware\")}  upgrade={d.get(\"upgrade-firmware\")}')"; done

Soll: bei allen vier current=7.24 upgrade=7.24.

Wenn etwas klemmt

Gerät kommt nach dem Reboot nicht zurück → 2–3 Minuten geben (RouterBOOT prüft nach einem Firmware-Wechsel beim ersten Start mehr als sonst). Danach: Strom aus/an.
Current Firmware bleibt alt → Reboot wurde übersprungen, Schritt 7 nachholen.
Kein Upgrade-Knopf sichtbar → das Gerät ist bereits aktuell.
Netz nach dem Core-Reboot still → erst prüfen, ob es wirklich am Core liegt: ping 10.40.99.1. Antwortet er, ist Layer 3 zurück und der Rest hängt an DHCP-Leases, die sich von selbst erneuern.

⚠️ Nicht während des Vorgangs parallel Golden-Config-Deploys laufen lassen — ein Reboot mitten im Netmiko-Push hinterlässt einen Teil-Zustand (bekannte TP22-Falle).

4.9 KiB Raw Blame History Unescape Escape