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>
This commit is contained in:
98
docs/routerboot-firmware-klickanleitung.md
Normal file
98
docs/routerboot-firmware-klickanleitung.md
Normal file
@@ -0,0 +1,98 @@
|
||||
# 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)
|
||||
|
||||
1. **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).
|
||||
2. Links im Menü **System** → **RouterBOARD**.
|
||||
3. 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.**
|
||||
4. Oben auf den Knopf **Upgrade** klicken.
|
||||
5. Rückfrage **„Do you really want to upgrade firmware?"** → **Yes**.
|
||||
6. Es erscheint sinngemäß *„Firmware upgraded, reboot for changes to take effect"*.
|
||||
**Die Firmware ist damit geschrieben, aber noch nicht aktiv.**
|
||||
7. Links im Menü **System** → **Reboot** → **Yes**.
|
||||
8. 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:
|
||||
|
||||
```bash
|
||||
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).
|
||||
Reference in New Issue
Block a user