# 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).