bf-infra/docs/handoff-20260915-tp25-zuordnung-und-redundanz.md

Handoff 2026-09-15 — TP25: AP-Zuordnung fixiert, Tausch-Befund, ap1-Redundanz gemessen

Anlass: Folgesession zur unklaren Tausch-Lage vom Vormittag (handoff-20260915-tp25-tausch-und-zuordnung). Ziele: (1) AP-Positionen definitiv per IP/MAC/Switch-Port klären, (2) ob die Messwerte den richtigen Geräten zugeordnet sind, (3) Rundgang-Messung im natürlichen Zustand, (4) ap1-Redundanz-Test (ap1 aus).

🔑 AP-Zuordnung — DEFINITIV (IP + MAC + Switch-Port)

Gerät	IP	ether1-MAC	Bridge/Mgmt-MAC	Radios (5G/2,4G)	Port	Position
ap1	.11	D0:EA:11:4D:40:E0	:E1	:E5 / :E6	core ether3	Sideboard (Wohnzimmer)
ap2	.12	D0:EA:11:4D:40:39	:3A	:3E / :3F	core ether21	Technik UG
ap3	.13	D0:EA:11:FF:16:9D	:9E	:9F / :A0	branch ether24	Technik OG

Beweis: Neighbor-Tabelle (MNDP, L2) + Bridge-Host-Tabelle + Port-Link-Status am Core, live gelesen.

⚠️ MAC-Korrektur: ap2s ether1 ist :39, nicht :3A. :3A ist die Bridge-/Mgmt-MAC (die CLAUDE.md als „ap2" führt). ap2s Radios sind :3E/:3F — das Handoff-09-15 hatte damit recht; meine frühere „um eins versetzt"-Korrektur war falsch (ich hatte :3A fälschlich als ether1-Basis angenommen).

Tausch-Befund — ap2↔ap3 statt ap1↔ap3

Geplant (Deckungsfix Variante 3): ap1↔ap3 (cAP ax → Sideboard, hAP → UG-Schatten). Tatsächlich getauscht: ap2↔ap3:

• ap1 blieb Sideboard (ether3)
• ap2 ging von OG → UG (ether21)
• ap3 (cAP ax) ging von UG → OG (branch ether24)

⇒ Drei-Wege-Drehung mit dem falschen Paar. Der „Deckenstrahler" (cAP ax) steht jetzt in OG, nicht am guten Platz (Sideboard). Ursache war die ap1/ap2-Verwechslung während der Session.

Rundgang 1 — alle APs an, natürlicher Zustand (ohne Fixierung)

Methode: Registration-Table am Manager im 1-s-Takt, iPhone F2:62:4C:E1:AF:09 auf dirtyvader-main.

• 0 Disconnects, Signal −45…−77 dBm (alles brauchbar, meist deutlich besser).
• Roaming natürlich über alle 3 APs (ap3→ap2→ap1→ap2→ap3) — funktioniert.
• Terrasse (das Sorgenkind): −58 dBm stabil an OG-Position (jetzt cAP ax), 2,4G.
• ap1 (Sideboard) wurde nur kurz gestreift (−52…−60); den Rest dominieren ap3 (OG) + ap2 (UG).
• Kein Band-Thrash: nur ein sinnvoller 2,4G-Ausflug bei 5G-Zellkante (−77), sonst sauber 5G.

Rundgang 2 — ap1 komplett aus (Redundanz-Test)

Methode (neues CAPsMAN-Wissen): ap1-Radios lassen sich nicht über cap-wifiN abschalten (failure: can not change dynamic interface). Richtig: Provisioning-Regeln auf action=none, dann re-provisionieren:

/interface wifi provisioning set [find where radio-mac=D0:EA:11:4D:40:E5 or radio-mac=D0:EA:11:4D:40:E6] action=none
/interface wifi capsman remote-cap provision [find where identity="ap1"]

Rückbau = action=create-dynamic-enabled + dieselbe re-provision. (Merkregel: cap-wifiN sind dynamische Interfaces; Abschalten geht nur über die Provisioning-Regel + re-provision.)

Ergebnis:

• Main-Client (iPhone): ohne ap1 voll abgedeckt (ap2+ap3), tiefster Wert −80 dBm (ap3/OG 5G, an der Terrasse — dieselbe bekannte Zellkante, nur diesmal auf 5G statt 2,4G erwischt), kein Disconnect.
• IOT: vorher 27 Geräte (19 ap1 + 8 ap2). Nach Abschalten alle 27 zurück — 23 auf ap2, 4 auf ap3. MAC-gegengeprüft, keiner verloren. Aber ~4 Geräte sitzen marginal bei −77…−80 dBm (Wohnzimmer-Geräte, vorher nah am Sideboard-AP, jetzt an der ap2/UG-2,4G-Zellkante).
• ap1 wieder eingeschaltet (Revert) — Zustand vor dem Test wiederhergestellt.

Befund: ap1 technisch redundant, aber 4 IOT-Geräte an der Kante

Aspekt	Ergebnis
Main-Client	✅ ohne ap1 voll abgedeckt, tiefster Wert −80, kein Disconnect
IOT (27)	✅ alle verbunden, aber ~4 marginal −77…−80 dBm

ap1 ist technisch redundant — nichts fällt aus, wenn es weg ist. Aber die ~4 Wohnzimmer-IOT-Geräte verlieren ihre Signal-Reserve (verbunden ja, Aussetzer-Risiko erhöht). „ap1 abbauen" ist eine echte Option, aber kein Selbstläufer.

Offen / nächste Schritte

1. Entscheidung ap1: behalten (Status quo) oder Richtung Abbau? Nur sinnvoll, wenn die ~4 marginalen IOT-Geräte akzeptiert werden (oder deren Platzierung/ap2-Abdeckung verbessert wird).
2. Tausch korrigieren? Aktuell cAP ax @ OG, hAP @ UG, hAP @ Sideboard — misst gut, ist aber nicht der geplante Zustand (cAP ax → Sideboard). Der Drei-Räume-Schatten (Schlafzimmer/Bad/Küche, 08-22: −82…−84) ist mit dem jetzigen Arrangement noch nicht verifiziert — der Rundgang lief ohne Raumnamen/Fixierung. Nächste Messung sollte die drei Räume gezielt prüfen.
3. Doku-Drift schließen (nicht in dieser Session angefasst): CLAUDE.md-Hardware-Tabelle (ap2-MAC :3A→:39 ether1, ap2 Position OG→UG, ap3 UG→OG, ap1 „FUNKSTILL" überholt), teilprojekte.md TP25-Abschnitt, Nautobot Location (nach wie vor None).
4. Gitea-Issue #17 trägt den Befund als Kommentar.

Übergabeprompt (nächste Session)

TP25 weiter: Die AP-Zuordnung ist jetzt definitiv geklärt (Handoff 2026-09-15 „zuordnung-und-redundanz"). ap1=Sideboard (core ether3), ap2=Technik UG (core ether21), ap3=Technik OG (branch ether24) — der Tausch hat ap2↔ap3 vertauscht statt ap1↔ap3, ap1 blieb stehen. Rundgang ergab: Coverage überall gut (0 Disconnects, −45…−77 dBm), Terrasse −58 stabil an OG, ap1 nur kurz gestreift. ap1-Aus-Test: Main-Client voll abgedeckt, alle 27 IOT-Geräte kehren zurück, aber ~4 Wohnzimmer-IOT sitzen marginal −77…−80 dBm. ap1 ist wieder an. Offen: (1) ap1 behalten oder abbauen? (2) Tausch auf Plan korrigieren (cAP ax → Sideboard)? (3) Drei-Räume- Schatten (Schlafzimmer/Bad/Küche) gezielt nachmessen. (4) Doku-Drift (CLAUDE.md MAC/Positionen, Nautobot Location) schließen.