Files
bf-infra/docs/handoff-20260915-tp25-tausch-und-zuordnung.md
Christoph Emsenhuber 3e727f1b3b TP25: AP-Zuordnung per Kabel-Test geklärt, Messrunde Vorher, Tausch ap1↔ap3 begonnen
Handoff der Vor-Ort-Session: ap1=Sideboard, ap2=Technik OG, ap3=Technik UG (per
Kabel-Test eindeutig). Messwerte Vorher (Innenräume + Terrasse) festgehalten;
Terrasse wird ausschließlich marginal von ap2 bedient. Tausch ap1↔ap3 angefangen,
aber Netzzustand unklar (ap2 down, ap3 an ether8). Nächste Schritte dokumentiert.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-09-15 17:11:17 +02:00

5.7 KiB
Raw Blame History

Handoff 2026-09-15 — TP25: AP-Zuordnung geklärt, Messrunde (Vorher), Tausch ap1↔ap3 begonnen

Anlass: Christoph wieder on site in Linz. Zurückgestellter Job = TP25 Deckungsfix Variante 3 („Deckenstrahler an den guten Platz, hAP in den Schatten"). Session lief als große Messrunde (Vorher) + physischer Tausch ap1↔ap3. Tausch ist physisch angefangen, aber der Netzzustand ist zum Sitzungsende unklar — ap2 ist down.

🔑 AP-Zuordnung — EINDEUTIG per physischem Test geklärt

Die Session lief lange mit vertauschter Zuordnung (auch Christoph hat sie zwischenzeitlich falsch „korrigiert"). Der Kabel-Test hat sie eindeutig festgelegt:

Gerät IP Position Uplink
ap1 10.40.99.11 Sideboard / Wohnzimmer core ether3
ap2 10.40.99.12 Technik OG core ether8 → branch ether24
ap3 10.40.99.13 Technik UG core ether21

Beweis: Christoph zog das Kabel in Technik OG → cap-wifi1/cap-wifi6 (= ap2, Radio-MAC D0:EA:11:4D:40:3E/3F) verschwanden aus der cap-wifi-Karte, ap1/ap3 blieben. ⇒ ap2 = Technik OG, ap1 = Sideboard. Die ARP zeigt ap2 noch ~30 s „reachable" (Cache), die CAPWAP-Karte ist die Wahrheit.

⚠️ CLAUDE.md-Drift: die Hardware-Tabelle sagt für ap1 „core ether15" — überholt, ap1 hängt an ether3. Und die Doku-Aussage „ap1 FUNKSTILL seit 08-30" ist überholt (ap1 dient live).

Messrunde (Vorher) — Methode

iPhone F2:62:4C:E1:AF:09 (Fund-E-Gerät) wurde per Access-List-Reject gezielt auf je einen AP gelenkt (die anderen zwei APs ablehnen), dann Registration-Table am Manager gelesen. Reject-Regeln nur auf ssid-regexp=dirtyvader-main, am Ende immer remove [find where comment~"TP25-messung"].

⚠️ Zwei Methodik-Gotchas (neu):

  1. interface= in der Access-List nimmt nur EINEN Wert (keine Komma-Liste) — pro AP zwei Regeln (5G- + 2,4G-Radio). Eine Komma-Liste wirft input does not match any value of interface.
  2. MAC-Tippfehler F2:62:4C:E1:41:AF:09 (ein „41" zu viel) ist mir zweimal passiert und hat stille Fehl-Reads (leere Registration-Table) erzeugt. Korrekt ist F2:62:4C:E1:AF:09.

Methodischer Vorbehalt: die wiederholten Rejects + Disconnects drosseln die iOS-Wiederverbindung. Ein „✗ tot"-Wert direkt nach mehreren Disconnects kann teils Artefakt sein — Christoph hat den ap1-tot-Befund auf der Terrasse aber selbst per manuellen Verbindungsversuchen bestätigt.

Messwerte (Vorher)

Innenräume (Durchschaltung, je Station alle 3 APs):

Ort ap1 (Sideboard) ap2 (OG) ap3 (UG)
Küche 5G −52 — —
Schlafzimmer 5G −52 ✗ tot 2,4G −57 / 5G −73
Bad 2,4G −71…−76 ✗ tot 5G −73 / 2,4G −72
Klo ✗ tot 2,4G −75…−81 5G −69
Technik OG (−52 erst, dann ✗)† 5G −47…−57 5G −68…−71

Terrasse (3 Runden je AP: sitzend → Rundgang entlang der Mauern → wieder sitzen):

ap1 (Sideboard) ap2 (OG) ap3 (UG)
Sitzend ✗ tot 5G −78…−85 / 2,4G −67 (Thrash) ✗ tot
Rundgang ✗ überall 2,4G −63…−74 / 5G −73…−75 ✗ (nur 1 Mauerdurchlass −70…−82)

† Vorbehalt s.o.

Kernbefunde:

  1. Die Terrasse wird ausschließlich von ap2 (Technik OG) bedient — marginal (Band-Thrash 5G −78…−85 / 2,4G −67). ap1 (Sideboard) erreicht die Terrasse nicht, ap3 nur an einem Mauerdurchlass kurz (−70…−82). Die Prämisse „Sideboard-AP deckt die Terrasse" ist widerlegt.
  2. ap1 (Sideboard) ist der Innenraum-König: Küche −52, Schlafzimmer −52, Bad −71…−76.
  3. ap3 (cAP ax, UG) hält als einziger beide Geschoße (UG: Schlafzimmer/Bad/Klo −69…−73, OG: Technik OG −68…−71 über die Decke).

Tausch ap1↔ap3 — Status UNKLAR (Sitzungsende)

Christoph hat ap1 und ap3 physisch getauscht: ap3 (cAP ax) liegt jetzt „am Kasten auf ap1-Position", bewusst „oben/unten ausgerichtet wie Deckenmontage" (Abstrahlwinkel). Ports/VLAN sollten laut Vorgabe gleich bleiben.

Live-Befund direkt nach dem Tausch (Vorsicht, Zustand kann sich noch setzen):

  • ap2 = down (10.40.99.12 ARP incomplete, fehlt in cap-wifi-Karte). Vermutlich Kabel beim Tausch abgezogen.
  • ap1 = reachable, noch an ether3 (Sideboard).
  • ap3 = reachable, aber Bridge-Host zeigt es an ether8 (branch), nicht an ether21.
  • ether21 ist leer.

⇒ Der Tausch ist im Netz noch nicht so angekommen, wie physisch beabsichtigt. Bevor irgendetwas weitergemessen wird: ap2 wieder einstecken und die tatsächliche Verkabelung (welches Kabel an welchem Gerät) klären.

Offen / nächste Schritte

  1. ap2 (Technik OG) wieder versorgen — Kabel prüfen, ARP 10.40.99.12 wieder reachable.
  2. Verkabelung nach dem Tausch verifizieren: Bridge-Host-Tabelle (mac-address~"D0:EA:11") gegen Soll (ap1=ether3, ap2=ether8/branch, ap3=ether21) stellen. ap3 hängt aktuell an ether8 — klären, ob das Absicht ist oder Verwechslung.
  3. Nachher-Messung derselben Stationen (Terrasse + Innenräume), erst wenn 1+2 sauber sind.
  4. Nautobot hat keine Location/Position für ap1/ap2/ap3 hinterlegt (location: None). Nach dem abgeschlossenen Tausch die korrekten Positionen dort nachtragen (SSoT-Drift schließen).
  5. Gitea-TP25-Issue #17 bekommt den Befund als Kommentar (Zitat auf Messwerte + Zuordnung).

Messwerte-Kurzform (für Folgesession)

cap-wifi-Karte war am Sitzungsende nach ap2-Rejoin: cap-wifi1=ap3-5G, cap-wifi2=ap3-2,4G, cap-wifi3=ap1-5G, cap-wifi5=ap1-2,4G, ap2 fehlte (down). Die cap-wifiN-Nummern verschieben sich bei jedem CAP-Rejoin — vor jeder Messung neu lesen (/interface wifi radio print terse proplist=cap,radio-mac,interface am Manager).