Christoph Emsenhuber
b93514a045
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>
14 lines
1.1 KiB
Plaintext
14 lines
1.1 KiB
Plaintext
# TP5 Etappe 4 — Auto-Revert abbestellen. Abnahme 2026-08-18 (input-Drop live):
|
|
# DNS aus VLAN20 an den Core core.bf.lan -> 10.40.99.1, heise.de -> 193.99.144.80
|
|
# AGH unveraendert nas.bf.lan -> 10.40.20.10
|
|
# MAIN->core admin 57 Pakete (MikroMCP/SSH laufen weiter)
|
|
# HA->core api 3 Pakete
|
|
# Die 5 mDNS-input-Regeln erstmals scharf: vlan30=87, vlan20=13 Pakete
|
|
# (standen seit dem Bau am 2026-08-14 auf 0)
|
|
# CAPsMAN ap1 + ap2 state=Ok
|
|
# Gedroppt wurde ausschliesslich Broadcast-Rauschen, fuer das der Core nie
|
|
# zustaendig war: MNDP (inzwischen explizit erlaubt), NetBIOS 137/138 aus
|
|
# VLAN20, SSDP-Announcements einer Sonos aus VLAN40.
|
|
:do { /system scheduler remove [find name="tp5e4autorevert"] } on-error={ :log info "tp5e4: abbestellen warf" }
|
|
:log info ("tp5e4: AUTO-REVERT entfernt, input-drop-disabled=" . [:tostr [/ip firewall filter get [find comment="TP5: input deny-by-default"] disabled]] . " seal-lan-disabled=" . [:tostr [/ip firewall filter get [find comment="TP10-seal-lan"] disabled]])
|