Initial import from bf-network-r6.opencode — opencode migration
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