From 9fdfb06c1c6a009a71b33c622b185f44074f5b0c Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Wed, 19 Aug 2026 13:34:40 +0200 Subject: [PATCH] Uebergabe korrigiert: der AP-Cleanup war falsch abgenommen Ich hatte "30 Clients vorher, 30 nachher, kein Aussetzer" attestiert. Genau diese Zahl hat einen laufenden Ausfall verdeckt: seit dem CAPsMAN-Cutover vom 17. war slaves-datapath auf beiden APs leer, IOT/MEDIA/UNTRUSTED/GUEST hingen in keiner Bridge, Clients assoziierten und bekamen nie DHCP -- 14 Stunden. Die Registration-Table zeigte derweil zufriedene Clients. Abnahme fuer WLAN-Umbauten ist eine frische DHCP-Lease pro SSID, nicht die Registration-Table. In der Uebergabe nachgetragen. Co-Authored-By: Claude Opus 5 --- docs/handoff-doku-session-20260818.md | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/docs/handoff-doku-session-20260818.md b/docs/handoff-doku-session-20260818.md index 52e80cf..fad119a 100644 --- a/docs/handoff-doku-session-20260818.md +++ b/docs/handoff-doku-session-20260818.md @@ -83,9 +83,34 @@ Chronologisch, alles verifiziert und committet: Quelle, DHCP-Option 42, ComplianceRule `system-ntp`. 6. **TP7.1 — SSDP-Relay** als LXC 108 auf pve. User-bestätigt: „sonos ist da!" 7. **TP28-Rest — GC-Modell auf CAPsMAN umgebaut.** Die APs trugen noch die komplette - Standalone-WLAN-Config aus TP3; abgeräumt ohne einen Client zu verlieren. + Standalone-WLAN-Config aus TP3; abgeräumt. 8. **TP19 und TP3.2 geschlossen.** +### ⚠️ Korrektur zu Punkt 7 — und die wichtigste Lehre der ganzen Nacht + +Ich hatte den AP-Cleanup mit „30 Clients vorher, 30 nachher, kein Aussetzer" abgenommen. **Das war der +falsche Maßstab.** Parallel lief bereits ein Ausfall, den genau diese Zahl verdeckt hat: + +Seit dem CAPsMAN-Cutover vom **08-17** war `/interface wifi cap slaves-datapath` auf beiden APs **leer** +— das einzige Feld, das die vom Manager erzeugten Slave-VAPs lokal in die Bridge hängt. Der Core schickt +`datapath.bridge=bridge` mit, der CAP übernimmt davon aber **nur die `vlan-id`**. Folge: `-iot`, `-media`, +`-untrusted` und `-guest` hingen **in gar keiner Bridge**. Clients assoziierten sauber und bekamen +**nie DHCP** — **14 Stunden lang**. `dirtyvader-main` lief weiter, weil `wifi1`/`wifi2` statische +Bridge-Ports sind, und hat den Ausfall getarnt. + +Gefunden und behoben hat es Christoph am 08-18 um 09:13 (Commit `1ba8260`): `dp-caps-slaves` +(`bridge=bridge`, bewusst **ohne** `vlan-id`) + `slaves-datapath` darauf, auf beiden APs. + +**Zwei Konsequenzen, die du kennen solltest:** + +1. **Die Registration-Table ist kein Abnahmekriterium.** Sie zeigte während des Ausfalls zufriedene + IOT-Clients — und ich habe damit „kein Aussetzer" attestiert. **Richtig ist eine frische DHCP-Lease + pro SSID.** Steht inzwischen so in `CLAUDE.md`. +2. **Es war nicht die TP5-Härtung**, obwohl der zeitliche Zusammenfall das nahelegt: `torch` auf vlan30 + am Core war leer **und** der TP5-Drop-Log zeigte nichts. Beides leer heißt: es kommt nichts an, es + wird nichts verworfen → **L2-Problem, nicht Firewall**. Diese Merkregel steht jetzt ebenfalls in + `CLAUDE.md` und ist bei künftigen „connect ok, kein DHCP"-Fällen der erste Griff. + **Nautobot-Betrieb:** der Stack hat sich zweimal selbst umgebracht. Ursache war der **Image-Healthcheck** (voller Django-Start alle 10 s, Aufrufe stapeln sich → ENOMEM → DSM räumt ab), nicht Celery. Behoben. Steht in TP21.