bf-infra/docs/teilprojekte.md

BF-Netzwerk — Teilprojekte (kanonische Steuerung, Stand 2026-06-10)

Zweck: Das große Netz-Projekt in einzeln durchziehbare Teilprojekte (TP) zerlegt — jedes mit klarem Scope, aktuellen Entscheidungen, Abhängigkeiten und Status. Jedes TP ist so geschnitten, dass es eine frische Session mit sauberem Kontext straight abarbeiten kann. Architektur/Historie: ~/.claude/plans/ich-will-das-delegieren-atomic-sunrise.md.

📚 Diese Datei führt den Ist-Stand, den kritischen Pfad und die OFFENEN Teilprojekte. Abgeschlossene TPs stehen im Archiv — im Volltext, unverändert, mit Inhaltsverzeichnis. Für den Einstieg reicht diese Datei; ins Archiv sieht man, wenn man wissen will, warum etwas so entschieden wurde. (Aufgeteilt am 2026-08-23, Doku-Session Punkt F: 2217 Zeilen waren zu 49 % Historie erledigter TPs.)

Kanonisches VLAN-Modell (gültig — überschreibt ältere Tabellen)

VLAN	Name	Subnetz (Ziel)	Zweck
10	MAIN	10.40.10.0/24	Trusted (Handy/Laptop/Apple Watch)
20	INFRA	10.40.20.0/24	NAS/VMs/Docker/HA
30	IOT	10.40.30.0/24	Smart-Home (HA-managed), Waage, Fitness-Tracker
40	MEDIA	10.40.40.0/24	Sonos, AppleTV, TV, VuPlus, Cast-Ziele (getauscht ggü. früher)
50	UNTRUSTED	10.40.50.0/24	Spielekonsole, eBook-Reader, Low-Trust-Internet
90	GUEST	10.40.90.0/24	nur Internet
99	MGMT	10.40.99.0/24	Switch/AP/Hypervisor-Mgmt
100	WAN	(Arris-Transfer)	zum Arris-Kabelmodem (Liwest, Bridge-Mode, Public-IP an crs326-core)
IP-Blöcke: .1–10 Router/Gateways · .11–20 Switches/APs. GW je VLAN = .1 (crs326-core).
Mgmt (VLAN99, Ist 2026-08-16): core .99.1 · branch .99.2 · ap1 .99.11 · ap2 .99.12.
(Historisch, überholt: „ap1=.1, ap2=.2 · ALLNET=.11, Omada=.12" — aus der Zeit vor dem Core-Cutover.)

Ist-Stand (Kurz)

Stand 2026-08-18 — live gegen die Geräte geprüft (MikroMCP/REST), nicht aus der Doku abgeschrieben. Die Compliance-Zeile unten ist am 2026-08-23 gegen die Nautobot-API nachgezogen. (Die Fassung vom 2026-08-16 stand bis zum 18. hier und war an vier Stellen überholt — Standalone-APs, RouterOS-Versionen, „plain 1.1.1.1", 68/68. Wer diesen Block liest, liest ihn als Erstes: er wird ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)

• Alle vier MikroTik laufen auf RouterOS 7.24 (stable, 2026-08-17 von Christoph selbst gehoben, TP27), RouterBOOT ebenfalls 7.24 auf allen vieren (current-firmware = upgrade-firmware, geprüft 08-18).
• L3 + WAN-Edge = crs326-core (CRS326-24G-2S+, Technik UG): Routing, DHCP (7 Server, 54 Reservierungen), DNS, NAT, NTP-Server für den Standort und der WG-Hub (TP10, Peers fm/dw) laufen hier. Mgmt-SVI 10.40.99.1 (vlan99), Gateway .1 je VLAN. WAN = vlan100 — DHCP-Client hält die öffentliche Liwest-IP 90.146.33.177/24 direkt vom Arris (Bridge-Mode) → kein Double-NAT. DNS-Upstream = DoH zum CF-Gateway mit verify-doh-cert=yes (TP23 Stufe 1 ✅ 08-18); servers=1.1.1.1 steht nur noch als Bootstrap für den DoH-Hostnamen.
• 🔥 Die Firewall ist deny-by-default — in BEIDEN Ketten (TP5 E3/E4 ✅ 08-18). TP10-seal-lan ist disabled; Mgmt-Input kommt nur noch aus VLAN10, von HA (8728), von Nautobot (22) und über cf-mesh. Ein neuer Dienst über eine VLAN-Grenze braucht ab jetzt eine explizite Regel.
• L2-Branch = crs326-branch (Technik OG): reiner L2-Switch, Mgmt 10.40.99.2, Uplink ether1 → core ether8.
• WLAN = CAPsMAN auf dem Core (TP28 ✅ 08-17, GC-Modell nachgezogen 08-18): ap1 10.40.99.11 (an core ether15), ap2 10.40.99.12 (an branch ether24), beide reine CAPs — cap enabled=yes, discovery-interfaces=vlan99. Die APs halten keine eigene WLAN-Config mehr; Kanäle, SSIDs, Security und Steering kommen vom Manager. 802.11r/k/v aktiv, ft-over-ds=yes.
• SSDP-Relay (TP7.1, nachgebessert 08-25): LXC 108 mcast-relay auf pve, zweibeinig 10.40.10.21 (VLAN10) + 10.40.40.21 (VLAN40) — dafür trägt core ether13 beide VLANs; mDNS macht weiterhin der Core. Läuft seit 08-25 ohne --ssdpUnicastAddr — die Flagge verwarf die M-SEARCH der App auf dem Weg nach VLAN40 (Messung: 0 Pakete via eth1 gegen 308 via eth0 in 20 min, 0× Received SSDP Unicast im ganzen Journal seit 08-18). Der Rückweg läuft jetzt nativ geroutet über die längst offene Regel TP5: MEDIA->MAIN; nachgemessen kommen HTTP/1.1 200 OK von 10.40.40.193/.195 an beiden MacBook-Beinen an. Unit liegt im Repo: mcast-relay/multicast-relay.service, Details als Gotcha in CLAUDE.md. ⚠️ Der Fall hatte zwei unabhängige Ursachen — nach der Relay-Reparatur suchte die App immer noch nicht (macOS-Local-Network-Gate stand auf „an" und griff nicht; Fix war Schalter aus/ein + Neustart, User-bestätigt 08-25). Beide sind erledigt.
• Ausgebaut / gelöscht: ALLNET-sw1 und Omada-sw2 sind physisch weg (2026-08-08 bzw. 2026-07-23, in Nautobot Decommissioned); Omada-Controller + omada-mcp gelöscht (2026-07-16); FritzBox 6660 raus seit 2026-07-01 (Liwest-Tausch auf Arris). VLAN1 ist leer (/ip arp auf bridge = 0 Einträge, 08-18) — TP19 ist geschlossen; cudy1 hängt stromlos an core ether11, physischer Ausbau ist hands-on.
• Kontrolle / Governance: MikroMCP für Reads/Debug (alle 4 Geräte in der Registry), Config-Änderungen ausschließlich über Nautobot Golden Config (TP21/TP22 — Deploy-Pipeline scharf, 104/104 Compliance-Checks grün, 0 Drifts bei 26 Rules × 4 Geräten — live gegen die API geprüft am 2026-08-23; zuletzt dazugekommen: wifi-access-list (08-22), queue (08-23, TP6) und ip-firewall-mangle (08-23, TP6.1), s. TP22-Nachtrag im Archiv). (Hier stand bis zum 08-23 „100/100 bei 25 Rules" — eine Zählung, die TP6.1 am selben Tag überholt hat. Die Merkregel gilt: der Ist-Stand-Block wird bei jeder Änderung mitgezogen, nicht nur der TP.)

📜 Historische Fassung (Stand bis 2026-08-08, Topologie vor dem Core-Cutover — bewusst erhalten, nicht als Ist lesen)

ALLNET-Core .11 (FW2.2.1, VLANs 10/20/30/40/50/90/99/100; GE1/GE2/GE8 Trunk; TP1 ✅ 2026-06-15). Omada-Switch .12 (adopted, TP2 ✅ 2026-06-15; Trunk-ALL auf P1+P2, Access-Profile auf P3-P8; Profile noch PVID=1 bis Omada-PVID-Fix). Omada-Controller .175 (DS923/macvlan, mbentley 6.2, 🟢 live). omada-mcp .176 (pve-LXC, StreamableHTTP, 🟢 live, 84 read-Tools; Controller-API v2 intern via christoph@emsenhuber.com). 2× hAP ax² (7.23.1): ap1 .1 (ALLNET P1) — TP4 ✅ 2026-07-01: Router + WAN-Edge (VLAN-Subinterfaces, DHCP, DNS, NAT, Public-Edge). ap2 .2 (Omada P2 — Trunk). Edge-Cutover ✅ 2026-07-01: FB6660 physisch entfernt (Liwest-Kabelmodemtausch, kein Zurück), Arris-Kabelmodem im Bridge-Mode; WAN = sw1 gi16 Access VLAN100 → gi15 Trunk → ap1 ether2 → vlan100 auf bridge (NICHT ether1); ap1 hält Public-IP direkt (Liwest, kein CGNAT), Double-NAT weg. Telefonie war auf der FB und wird nicht weitergeführt. Vorarbeit: TP10-Kern durch (2026-06-27, WG-Hub live) → Bridge-Gate vorher gelöst. Runbook: routeros/wan-cutover-runbook.md. Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Controller + omada-mcp 🟢.

Nächster Schritt (Stand 2026-08-25): TP31 — Caddy als Reverse Proxy für innen und außen.

🆕 Neu am 2026-08-24/25: TP31 löst TP16 und TP16.2 ab und dampft cloudflared von sechs Containern auf einen ein; TP32 gibt die Nummern- und Adress-Systematik vor (und hat nebenbei die falsche Startreihenfolge auf pve repariert — HA startete vor seiner Datenbank). TP16 ✅, TP25 ✅ und TP16.3 (Pilot) ✅ sind am 24./25. durchgezogen worden.

Vorherige Fassung (Stand 2026-08-23): Christoph entscheidet — der kritische Pfad ist LEER.

🎯 Das Projekt ist in seinem Kern fertig. deny-by-default steht (TP5), Golden Config steht und meldet 104/104 compliant bei 0 Drifts (live geprüft 2026-08-23), WLAN steht über CAPsMAN auf dem Core (TP28), VLAN1 ist leer (TP19) — und TP6 ist beantwortet statt offengelassen: CAKE gebaut, gemessen, wieder ausgebaut. Nichts blockiert mehr etwas. 🟢 Was zuletzt wirklich etwas gebracht hat, war TP6.1 (2026-08-23): nicht Shapen, sondern Klassentrennung — NAS-Bulk priority=8 gegen interaktiv priority=1 drückt dieselbe Strecke unter derselben Sättigung von 40,8 auf 11,0 ms (−73 %). Die zuerst notierte DOCSIS-Erklärung aus TP6 ist damit widerlegt; der Fehler lag in der Messmethode (Last und Messung vom selben Host). 📋 Offen und ohne Blockadewirkung: TP25 (Fund F = 5:05-Takt bei IoT, plus die Entscheidung „5 GHz auf 20 MHz") · TP16 (CF-Tunnel-HA degradiert, vier tote Alt-Tunnel) · TP16.2/16.3 · TP23 Stufe 2 · TP24 (DC-USV) · TP13/TP14.4 (beide mit fertigem Runbook) · ❌ TP17.1 VERWORFEN 2026-08-23 (Zigbee-Weg bewiesen, Ziel damit nicht erreichbar — das Gerät bleibt WLAN-Client; s9 zurückgebaut) · ✅ TP17.3 ERLEDIGT (Ursache eco_mode bewiesen; s23 + s26 repariert; eco_mode flottenweit aus, 22/22 außer s24) · ➡️ TP17.2 ist am 2026-08-24 in TP30 aufgegangen (Shelly-Gerätepasswort = Erstvergabe eines Credentials; TP30 ist das Sammelbecken dafür) · 🔑 Alle Passwort-/Token-Rotationen sind seit 2026-08-24 TP30 (Sammel-TP) — bewusst gebündelt gegen Projektende, User-Entscheid. Damit ist die ältere Einreihung „hinter TP17.1" gegenstandslos (TP17.1 ist verworfen). Etappe 1 — die Service-Accounts — ist durch; das admin-Passwort selbst ist nicht rotiert und bleibt es bis dahin bewusst. 📌 Einstieg für die nächste Session: handoff-20260824-session.md — ⚠️ dessen Empfehlung „Start bei der Passwort-Rotation Etappe 2" ist durch den TP30-Entscheid überholt; der Rest der Übergabe gilt. Ältere Sitzungsvorschläge: handoff-20260822-naechste-schritte.md. ✅ crs326-core ist transaktionsfrei (seit 2026-08-22, geprüft): ein gemeldeter Drift ist ab jetzt echt, nicht beabsichtigt — python3 nautobot/gc-transaktion.py status.

📜 Vorherige Fassungen dieses Absatzes (2026-07-22 → 2026-08-21, bewusst erhalten)

Fassung 2026-08-21 abends (erledigt — TP25s Dead Spot ist am 08-22 repariert, TP6 am 08-23 geschlossen): Nächster Schritt: TP25 — Steering-Test in den Schlafräumen. 📋 Einstieg: handoff-tp25-session-20260821.md — dort steht der verifizierte Ist-Stand, die Messfallen und der nächste Test. ✅ crs326-core ist transaktionsfrei (2026-08-22). TEST-ether3-trunk-ap1-sideboard und TEST-infra-ssid-matter-pairing sind beide zurückgerollt und geschlossen; ap1 hängt wieder auf ether15, ether3 ist wieder untagged VLAN40. Ein gemeldeter Drift ist ab jetzt echt, nicht beabsichtigt — python3 nautobot/gc-transaktion.py status. 🆕 TP29 (Anwesenheitserkennung fürs Energiesparen) ist als Idee angelegt, nicht auf dem Pfad. 📌 Die TP6-Prämisse ist am 2026-08-20/21 gemessen (Runbook §5): formal Fall B (+28…+47 ms unter Dauer-Upload), aber im Videocall nicht wahrnehmbar — kein einziger Problem-Klick über sechs Lastphasen. Laut war stattdessen der Funk: Sticky Client + Band-Ping-Pong, zwölf Wechsel in neun Minuten, je Wechsel bis zu 4 s ohne Durchsatz → tp25-wlan-roaming-messung-20260820.md. Deshalb steht jetzt TP25 vor TP6; TP6 bleibt offen und begründet, aber nachrangig.

Vorherige Fassung (Stand 2026-08-18, erledigt): TP6 wird hier seit Monaten als „DAS Ziel" geführt, aber docs/call-quality-diagnosis.md hat den Bufferbloat 2026-06-16 bereits gemessen (A/A+, „CAKE wäre marginal, nicht deployt"). Die Messung stammt aus der FritzBox-Ära, der Edge ist seither getauscht — also einmal gegen den heutigen Edge nachmessen und dann entscheiden. Blocker gibt es keine mehr. TP5 ist in der Nacht auf den 18. abgeschlossen worden (Etappe 3 + 4: deny-by-default in forward und input, MGMT isoliert, seal-lan abgeschaltet), TP23 Stufe 1 (DoH auf dem Core) ebenfalls. Nebenher offen, blockiert nichts: TP25 (Signal-Boden + Re-Walk), TP28-Rest (die fünf wifi-*-Features vom AP-Scope auf den Core umhängen — die einzigen verbliebenen Compliance-Drifts), TP7.1 (SSDP-Relay für die macOS-Sonos-App), TP16.3, TP24. Vorherige Fassung (Stand 2026-08-14, überholt): „TP5 — Deny-by-default am Ende von forward." Alles Davorliegende ist durch: CRS326-Bring-up + L3-Umzug ap1→crs326-core (TP15/TP21.1 ✅ 2026-08-08), WLAN-Neuprovisionierung ohne CAPsMAN (TP3 ✅ 2026-08-08), Nautobot-Plattform + Fleet-Adoption + Deploy-Pipeline (TP21/TP22 ✅ 2026-08-13). Danach TP6 (CAKE) = das Projektziel. Kleine Follow-ups nebenher: DoH-Cloudflare auf core, DC-USV (TP24, seit 2026-08-16 eigener TP). ⚪ Omada-PVID-Fix ist obsolet (User-Entscheid 2026-07-22 — Omada spielt seit der TP15-Korrektur keine Rolle mehr im Netz, nie mehr aufgreifen). Vorherige Fassung (Stand 2026-07-22, erledigt): „TP15 CRS326-Bring-up als neuer L3-Core, danach WLAN-Neuprovisionierung ohne CAPsMAN; TP5 folgt nach TP21/CRS326-Adoption."

🎯 Ziel: sauberes System „from scratch", keine Leichen/Altlasten. Migrations-Session-Endstand = VLAN1 + altes cudy-WLAN komplett weg (VLAN1 nur noch Mgmt, defconf-Client-DHCP zurückgezogen, cudy-Uplinks aufs Ziel-Client-VLAN getaggt oder cudy abgebaut). Unterpunkte/Aufräum-Liste bei Migration: (a) die Interim-Härtung ap2 wifi1/wifi2 frame-types=admit-only-vlan-tagged (TP3.1, 2026-07-06) bleibt gültig — verschwindet automatisch mit VLAN1; (b) st-main rrm/wnm = reines Roaming-Provisorium → kein Provisorium mehr (2026-08-13, TP3.3): Steering ist fester Bestandteil des Golden-Config-Templates + ComplianceFeature wifi-steering — es war die Neuprovisionierung, die es stillschweigend verloren hatte; (c) cudy1 = verbleibender aktiver VLAN1-Leak → ERLEDIGT (User-bestätigt + verifiziert 2026-08-14): cudy1 ist offline. core ether11 trägt kein Link (kein R-Flag), Nautobot-Status Offline (TP22 Schritt 5). Damit existiert kein aktiver VLAN1-Leak mehr; der Dual-DHCP-Race aus project_vlan1_dhcp_incident ist Historie. Der formale Teardown (Gerät ausbauen, Doku/Inventar) bleibt TP19. ⚠️ HW-Constraint hAP ax²: 1 GB RAM, aber nur 128 MB Flash + KEIN USB → Container auf dem Router NICHT praktikabel. Folge: native RouterOS-Features bevorzugen (z.B. Built-in-mDNS statt Container); Container (mDNS-Reflector, BIND9-DNS, Omada-Controller) laufen auf NAS/pve, nicht am hAP. 🔒 Governance-Entscheid (User, 2026-07-16, ausgeweitet 2026-07-16): Config ausschließlich über Nautobot — keine Direkt-Changes mehr an einzelnen im Netz verstreuten Geräten. Ursprünglich als ap1/ap2-Config-Freeze bis TP21 formuliert, noch am selben Tag verallgemeinert: jede Netz-Gerätekonfiguration (Router, APs, künftig auch die CRS326-Switches) läuft ab jetzt exklusiv über Nautobot Golden Config (TP21), sobald das steht — keine ad-hoc MikroMCP-Writes/UI-Klicks mehr an Einzelgeräten. TP19.1 war die letzte Ausnahme (ap1-DNS-Fix + ap2/sw1/sw2-Mgmt-VLAN-Umzug, s.u.) — davon ist nur der risikolose ap1-Teil noch direkt gemacht worden, ap2 wurde bewusst auf „nach Nautobot" vertagt. Macht Nautobot + alle Prerequisites (TP18→TP20→TP20.1→TP21, jetzt auch Komodo) zum aktuell kritischen Pfad, vor TP5/TP6. Betrifft nicht Software-Migrationen auf NAS/pve (anderes Substrat) und die Frage, ob sw1/sw2 vor der CRS326-Ablösung noch angefasst werden (offen, s. TP15/TP19.1). ✅ Genehmigte Ausnahme (User, 2026-07-17): der zentrale CF-Tunnel-Zugang auf ap1 (TP16/TP16.1). Alle für den zentralen Cloudflare-Zugang auf ap1 notwendigen (Vor-)Arbeiten dürfen direkt via MikroMCP/CF-API gemacht werden, ohne auf Nautobot GC zu warten — konkret die nativen WireGuard-Mesh-Zeilen aus TP16.1 (und analoge cloudflared/WG-Anpassungen am ap1-Edge). Begründung: Remote-Erreichbarkeit ist die Voraussetzung, um überhaupt sicher am Netz zu arbeiten (Henne-Ei zu Nautobot). Scope-Grenze: Die Ausnahme gilt nur für ap1. Sobald der zentrale Zugang später auf die CRS326 wandert (TP15), gilt die Ausnahme dafür vorerst NICHT — CRS326-Config läuft dann regulär über Nautobot GC (oder braucht eine eigene, dann neu zu erteilende Ausnahme). Nachtrag der ap1-Ausnahmezeilen in die GC als Follow-up, sobald Nautobot steht. ✅ Genehmigte Ausnahme #4 (User, 2026-08-16): die WireGuard-Zeilen des Cloudflare-Mesh-Bring-ups auf crs326-core (TP16.1). Dürfen direkt via MikroMCP/REST gesetzt werden. Begründung ist strukturell, nicht bequem: TP22-Regel 1 schließt jede Sektion mit <<REDACTED>> generell vom GC-Push aus, und /interface wireguard ist genau so eine — ein privater Schlüssel ist über Golden Config nicht deploybar. Damit ist die frühere TP16.1-Zusage „CRS326-Zeilen laufen regulär über GC" gegenstandslos. Auflage: vorher /system backup, danach Ist-Stand als intended config zurück nach Nautobot. Scope-Grenze: nur der Mesh-Bring-up auf crs326-core — nicht spätere WG-Änderungen, nicht andere Geräte, und sie verlängert sich nicht automatisch. Langfristige Auflösung = das Secret-Handling-Design in TP16.1 (Privkey ist Geräte-Identität, nicht Config). ✅ Genehmigte Ausnahme #2 (User, 2026-07-22): der CRS326-Bring-up (TP15). Die Grundkonfiguration beider CRS326 — Management-IP, Bridge, VLAN-Filtering, Trunks/Access-Ports — darf direkt via MikroMCP/Winbox gemacht werden. Begründung = Henne-Ei: Golden Config kann nicht auf ein Gerät pushen, das im Werkszustand keine erreichbare IP hat, und die GC-Templates existieren noch nicht (TP21 „offen: Templates/intended config"). Auflage: der so entstandene Ist-Stand wird anschließend als intended config nach Nautobot zurückgeschrieben, danach übernimmt GC — die Ausnahme deckt das Bootstrapping, nicht den Dauerbetrieb. Scope-Grenze: gilt für die beiden CRS326 im Bring-up. Sie hebt die Regel für ap1/ap2 nicht auf (deren Neuprovisionierung läuft weiterhin über GC) und verlängert sich nicht automatisch auf spätere CRS326-Änderungen. Damit ist die frühere Formulierung in TP16.1 („CRS326-Config läuft regulär über Nautobot GC oder braucht eine eigene, dann neu zu erteilende Ausnahme") erfüllt — dies ist diese Ausnahme.

---

Offene Teilprojekte

Alles hier hat noch offene Arbeit. Abgeschlossenes steht im Archiv (Volltext, mit Inhaltsverzeichnis) — die Zuordnung ist mechanisch: ein TP wandert erst dann ins Archiv, wenn nichts mehr daran zu tun ist. Wo nur ein Sub-TP offen war, steht dieses hier und das erledigte Eltern-TP im Archiv (so bei TP17.2 ↔ TP17 (TP17.2 ist am 2026-08-24 in TP30 aufgegangen und kein eigenes TP mehr) und TP20.1 ↔ TP20).

TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt

• Kontext (2026-07-08/09): Airfryer „airschreier" (Philips/Versuni, ESP, 10.40.30.180) bekam per DHCP-Option 6 dns 1.1.1.1 als Override, weil das OTA-Update über den ap1-DoH-Gateway-Pfad nicht durchging (DoH-Latenz beim primitiven ESP-Stack — kein Content-Block, via Gateway-Logs bewiesen, s. memory/ref_esp_ota_doh_not_block). Nebenwirkung: public 1.1.1.1 = anonymer Consumer-Resolver ≠ accountgebundener Gateway-DoH (px35ynlol3.cloudflare-gateway.com) → DNS-Sicht auf das Gerät weg, Gerät umgeht zudem die Filterung.
• (a) DNS-Redirect statt Geräte-Override (der dauerhafte Fix): dst-nat „UDP/53 (+TCP/53) von Low-Trust-Src → auf einen plain Resolver umbiegen" gibt Logging zurück UND funktionierendes OTA (kein langsamer DoH-Pfad fürs Gerät). Redirect-Ziel-Optionen: (i) ap1-Resolver mit nicht-DoH-Upstream für dieses Src-Set, (ii) direkt public 1.1.1.1 (dann nur Flow-Logging), (iii) eigener plain-Resolver. Sauberer als „Gerät verschwindet auf 1.1.1.1". Verortung: Teil des UNTRUSTED-Internet-only-Pinnings (TP5-„Offen"); Entscheidung v50-DNS-Policy (gefiltert vs. plain) hängt dran.
• (b) Live-Torch als Ad-hoc-Observability: DNS ist bei direktem 1.1.1.1 blind, Flows nicht (NATen über ap1). torch auf vlan30/vlan50 gefiltert auf die Geräte-IP zeigt Ziel-IPs live (Versuni → AWS eu-west-1 IoT erkennbar). Voraussetzung: Gerät aktiv. Merkregel: Airfryer nur online wenn er kocht → Capture ans Einschalten koppeln.
• Abh.: UNTRUSTED-Move des Airfryers (Kandidat, s. VLAN50) + TP5-Deny-by-default. Kein Blocker.

TP8 — Identity & Access-Control ▸ research-gated

• RADIUS = FreeRADIUS auf der NAS (✏️ User-Manager v5 kann KEIN LDAP → openldap nur via FreeRADIUS anbindbar).
• EAP-TLS (Zert) je Gerät + dynamische VLAN-Zuweisung (RADIUS-Attribut Tunnel-Private-Group-ID). Einfachste Heim-Alternative: pro VLAN eine SSID mit WPA3-PSK (kein RADIUS) — Abwägung Komfort vs. Admin-Aufwand.
• Abh.: TP3. (Research erledigt, s. TP-R.)

TP11 — Monitoring & Mgmt-Control-Plane ▸ research-gated

• MikroMCP + omada-mcp + SNMP/icinga-mikrotik, RoMON, NTP, E-Mail-Alerts, Netwatch. → Teil von docs/research/routeros-capabilities.md.
• CF-Tunnel #1033 Track A ✅ live (2026-06-30): Round-Robin-1033er über 3 asymmetrische Connectors behoben durch Reduktion auf pve-only Connector (NAS + macmini scheiterten an pve-lokalen/stalen Origins). SSoT: docs/cf-tunnel-mapping.md. Track B/C läuft über TP14 (Ingress bereits v116 .41→.20 für NAS; pve-Connector→VLAN20 via TP14 Session B = #1033-Zielbild).

TP12 — IPv6 (intern + extern, 3 Standorte) ▸ research-gated

• Konzept für FM/BF/DW. → TP-R.

TP12.1 — IPv6 im LAN (ULA) + v6-Firewall ▸ 🟠 KONKRET GEWORDEN (2026-08-22), Treiber: Matter/Thread

Anlass: der runde IKEA-Fühler TIMMERFLOTTE (Matter over Thread) ließ sich nicht anlernen — „pairing failed" in der Companion-App. Ursache ist nicht die Firewall, sondern dass zwischen VLAN10 und VLAN20 überhaupt kein IPv6 geroutet wird. Damit ist TP12 vom Konzept-TP zu einem Punkt mit einem konkreten, wiederkehrenden Schaden geworden.

• Befund am crs326-core (live gelesen 2026-08-22):

  • IPv6-Adressen: ausschließlich Link-Local (fe80::…) auf jedem Interface. Keine ULA, keine GUA.
  • IPv6-Routing-Tabelle: nur ::1/128 und fe80::/64 je Interface. Keine Route auf den Thread-OMR-Prefix fd92:505a:c64e:1::/64 und keine auf fd03:cace:953f:e13d::/64 (den On-Link-Prefix, den der OTBR auf VLAN20 wirbt).
  • /ipv6 nd: Default-Eintrag, advertise-dns=no — es gibt aber ohnehin keine Prefixe zu werben.

• 🔴🔴 Der eigentliche Kostenpunkt ist nicht IPv6, sondern die Firewall: /ipv6 firewall filter ist komplett leer. Heute harmlos, weil ohne Adressen nichts geroutet wird. In der Sekunde, in der Adressen vergeben werden, steht IOT→MAIN offen, GUEST→INFRA offen — an TP5 vorbei. Das gesamte TP5-Regelwerk muss vorher in v6 nachgebaut sein, sonst reißt dieser TP genau die Segmentierung auf, die TP5 am 2026-08-18 geschlossen hat. Das ist die Arbeit, nicht die Adressvergabe.

• 🔎 Warum Matter das braucht: Commissioning läuft in zwei Etappen. Etappe 1 (BLE zum Gerät) ist netzunabhängig. In Etappe 2 muss der Commissioner — das iPhone — das Gerät auf dem operativen Thread-Netz wiederfinden (DNS-SD _matter._tcp, dann CASE). Dafür braucht das Telefon eine IPv6-Route in den OMR-Prefix hinein. iPhone hängt auf VLAN10, OTBR auf VLAN20 → Etappe 2 bricht ab. Die ~30 bereits laufenden Matter-Knoten widersprechen dem nicht: HA und OTBR sitzen auf demselben Host (wpan0 ist lokal), im Betrieb quert nichts die VLAN-Grenze. Nur das Anlernen tut es.

• ⚠️ Zwei Fallen, die den naiven Weg verbauen:

  • (a) Der OMR-Prefix ist generiert und wandert. Am 2026-08-22 um 17:33 (OTBR-Neustart) sind alle Knoten von fd92:505a:c64e:1::/64 auf Mesh-Local fd66:986:170:bb1a::/64 gefallen — und Mesh-Local ist per Definition nicht off-mesh routbar. Eine statische Route auf den OMR-Prefix ist also nur so stabil wie der nächste Neustart. Ihn im Thread-Dataset festzunageln formiert das Netz neu — mit 30+ produktiven Knoten daran kein Nebenbei-Change.
  • (b) RouterOS lernt fremde RAs nicht. Der OTBR wirbt den OMR-Prefix per RA mit Route-Information-Option auf VLAN20. Der Core müsste die annehmen — als forwardender Router für dieses Interface tut er das nicht sauber.

• 📡 Dritter Baustein: DNS-SD über die VLAN-Grenze. mdns-repeat-ifaces am Core (vlan10/20/30/40/90) ist IPv4. Für Matter-Discovery bräuchte es zusätzlich einen v6-fähigen Reflector — der mcast-relay-LXC (108) kann das prinzipiell, aber als zweite Instanz mit Beinen in VLAN10+VLAN20 (SSDP-Instanz ist VLAN10+VLAN40, s. Gotcha in CLAUDE.md).

• ✅ Der Workaround, der das umgeht statt löst: iPhone zum Anlernen auf VLAN20 — dann sind Telefon und Border Router auf demselben L2-Link, der OTBR wirbt dort On-Link-Prefix und Route, und iOS wertet beides aus. cfg-infra / SSID dirtyvader-infra (dp-infra, VLAN20, sec-infra mit PSK) existiert am Manager bereits, ist nur in keiner provisioning-Zeile als Slave hinterlegt. Runbook: docs/matter-pairing-infra-ssid-runbook.md.

• ✅ 2026-08-22 durchgefuehrt und wieder zurueckgebaut. dirtyvader-infra temporaer auf ap2 (Transaktion TEST-infra-ssid-matter-pairing, Scope wifi-provisioning), iPhone dort hinein, TIMMERFLOTTE per Companion-App angelernt — liefert 25,44 °C / 53,1 % rF / Batterie 100 % (Bereich Technik UG). Danach SSID deaktiviert; cfg-infra/dp-infra/sec-infra bleiben auf User-Wunsch inaktiv am Manager stehen, damit der Weg beim naechsten Thread-Geraet ein Zweizeiler ist. Beide Akten geschlossen, crs326-core transaktionsfrei. ⇒ Der Workaround ist damit bewiesen — und TP12.1 bleibt trotzdem offen: er umgeht das fehlende IPv6-Routing, er behebt es nicht.

• ✅ Der Weg, der das Problem dauerhaft erledigt: Matter-Server-Option ble_proxy: true (ab HA 2026.06, hier 2026.8.3). Dann kommissioniert HA selbst über seinen Bluetooth-Stack; das Telefon ist raus und die VLAN-Grenze wird nie berührt. Braucht eine connectable BLE-Quelle — Shelly-Proxies sind reine Advertisement-Scanner (kein GATT), ein ESP32 als ESPHome-BT-Proxy (active: true) reicht. Der ESPHome Device Builder ist bereits installiert. Damit wäre TP12.1 für Matter optional. 🔴 User-Entscheid 2026-08-22: ESP32 wird NICHT angeschafft. Damit bleibt ble_proxy zwar an (schadet nicht, kostet nichts), ist aber wirkungslos — HA hat keine connectable BLE-Quelle und wird auch keine bekommen. Konsequenz, die man beim nächsten Thread-Gerät kennen muss: der Weg ist dann wieder die temporäre -infra-SSID nach dem Runbook. Die ist inzwischen ein Zweizeiler, weil cfg-infra/dp-infra/sec-infra am Manager stehen bleiben — aber sie ist jedes Mal ein Config-Change am Core plus eine Transaktion. Wer das dauerhaft loswerden will, muss TP12.1 bauen (v6-Firewall zuerst); ein dritter Weg ist damit nicht mehr vorgesehen.

• 🔎 Nebenbefund 2026-08-22, gehört zur Thread-Gesundheit, NICHT zu IPv6: drei Matter-Knoten flappen dauerhaft — @1:a („Diele OG/Treppenauge"), @1:f und @1:10. Muster im Matter-Server-Log: IpServiceStatus … Resolving (address is unreachable), dann offline grace period expired, marking unavailable, im Abstand von 15–30 Minuten, über Stunden. Die übrigen ~20 Knoten sind stabil, es ist also kein Border-Router- oder Fabric-Problem. ⚠️ Vor einer Diagnose die Sonderlage von heute abziehen: der OTBR ist am 2026-08-22 um 17:33 neu gestartet (Knoten fielen kurzzeitig von OMR fd92:… auf Mesh-Local fd66:… zurück), und ap1 war zwischenzeitlich vom Netz. Erst nachsehen, ob das Flappen danach noch besteht — sonst diagnostiziert man das Nachbeben eines Umbaus. Erste Verdachtsrichtungen, wenn es bleibt: Thread-Routing/Parent-Wechsel dieser drei Knoten, schwache Funkstrecke zum nächsten Router-Knoten, oder eine ICD-/Sleepy-End-Device-Eigenheit dieser Geräteklasse.

• Abh.: hängt an nichts. Blockiert nichts — außer künftige Thread-Geräte, solange weder ble_proxy noch die -infra-SSID steht. Reihenfolge innerhalb des TP ist zwingend: v6-Firewall nachbauen → dann erst Adressen vergeben. Gehört unter TP12 (Gesamtkonzept 3 Standorte), ist aber allein für BF ausführbar.

TP13 — „Botschafts-WLANs" ▸ 🔜 AUSFÜHRBAR (Runbook 2026-08-19) — docs/tp13-botschafts-wlan-runbook.md · fun/low-prio

📌 Am 2026-08-19 überarbeitet: der Technikteil beschrieb noch Standalone-APs (SSIDs entstehen seit TP28 am Manager, also ein Deploy statt zwei), und der Entwurf „nur ssid=, kein Security" war ein Denkfehler — eine SSID ohne Security ist ein offenes WLAN, also genau der Fall, den der Rechtsvorbehalt ausschließen soll. Richtig: PSK, den niemand kennt. Dazu die Datapath-Falle (Slave-VAP ohne vlan-id landet ungetaggt in der Bridge — dieselbe Mechanik wie der 14-h-Ausfall).

• Idee: eine/mehrere Broadcast-only-SSIDs als „schwarzes Brett" an die Funk-Nachbarschaft — der SSID-Name ist die Botschaft (z.B. Kanal-11-bitte-freihalten, WLAN-Tuning-siehe-Portal). Optional ein offenes WLAN mit Captive-Portal auf eine statische Info-HTML (Kanalabsprache, Auto-Kanalwechsel-Bitte). Leitgedanke: wer die SSID sieht, kann auch stören → die Infoseite erreicht genau die Zielgruppe.
• Technik (jetzt einfach, da WLAN standalone seit TP3-Rebuild): reine Namens-SSIDs = zusätzliche /interface/wifi Slave-VAPs auf wifi1/wifi2 mit eigener configuration (nur ssid=, kein Security/Datapath) ⚠️ Überholt 2026-08-19, in zwei Punkten:
  • (a) WLAN ist seit TP28 nicht mehr standalone. SSIDs entstehen am Manager crs326-core (9 configuration-, 6 datapath-Objekte, 4 provisioning-Zeilen — live gelesen 08-19). Das ist für TP13 sogar einfacher: ein Deploy statt zwei.
  • (b) 🔴 „kein Security" ist ein offenes WLAN — genau das, was der Rechtsvorbehalt unten ausschließen will. Richtig ist eine SSID mit WPA2/WPA3-PSK, den niemand kennt: sie beacont den Namen, ist aber nicht beitretbar.
  • Captive-Portal-Variante (RouterOS-Hotspot, isoliertes VLAN, walled-garden) bleibt als Option bestehen — s. Rechts-Gate unten.
• Umsetzungs-Skizze: … Beacon-SSIDs in routeros/.secrets/ap{1,2}-prov-base.rsc ergänzen … → diese Dateien sind für den WLAN-Teil Historie (die CAPs sind auf die cap-Zeile eingedampft). Aktuelle Umsetzung: docs/tp13-botschafts-wlan-runbook.md (2026-08-19).
  • 🔴🔴 Die Falle, die dort ausführlich steht: ein Slave-VAP ohne explizite vlan-id am Manager landet ungetaggt in bridge — weil der CAP vom Manager-Datapath nur die vlan-id übernimmt. Das ist dasselbe Leck wie TP3.1 (cfg-main-2g ohne datapath) und dieselbe Mechanik wie der 14-h-Ausfall vom 08-18. Die Botschafts-SSID braucht deshalb einen Datapath mit totem vlan-id — PSK und toter Datapath, nicht eines von beidem.
  • ✅ VAP-Budget geprüft (live 08-19), unkritisch: max-interfaces=16 je Radio, belegt sind 4 (5 GHz) bzw. 5 (2,4 GHz). Die Grenze ist Airtime, nicht die Zahl — jeder VAP beacont eigenständig. Empfehlung: genau eine SSID, auf 2,4 GHz (mehr Reichweite = mehr Nachbarn, und 5 GHz bleibt für Nutzverkehr frei).
• ⚠️ Recht vor Scharfschalten prüfen (User privat, AT): offenes WLAN + Portal berührt Impressumspflicht/Störerhaftung — reine Namens-SSIDs ohne offenen Zugang sind unkritisch (kein Fremd-Datenverkehr); im Zweifel nur die Beacon-Variante.
• Abh.: TP3-Rebuild ✅ (Standalone-APs — SSID-Änderung = 1 Deploy/GC-Job) → TP28 ✅ (CAPsMAN auf dem Core) + TP22 ✅ (GC-Deploy-Pipeline). SSID-Änderung = ein Deploy auf den Core; Direkt-Edit am Gerät ist durch den Governance-Entscheid ausgeschlossen.

TP14.4 — Session D: CF-Access-Profil für Claude ▸ 🔜 AUSFÜHRBAR (Runbook 2026-08-19) — docs/tp14.4-cf-access-token-runbook.md · nicht cutoff-kritisch

📌 Ist-Stand geprüft: in mcp/cloudflare/.env stehen weder CF_ACCESS_CLIENT_ID noch _SECRET — es ist also nichts halb erledigt. ⚠️ Das Secret existiert nur im Moment der Rotation. Abnahme braucht beide Fälle (mit Headern antwortet / ohne Header 403), sonst ginge ein bypass-Hostname wie vw fälschlich als Erfolg durch. Kein CF-Write erfolgt.

• CF-Token „claude code mcp" hat jetzt Access: Service Tokens: Write+Read → claude-mcp rotieren (POST …/access/service_tokens/{id}/rotate) → CF_ACCESS_CLIENT_ID/_SECRET in mcp/cloudflare/.env (chmod600). Memory ref-cf-access-claude-profile.
• 📋 Runbook: docs/tp14.4-cf-access-token-runbook.md (2026-08-19). Ist-Stand verifiziert: mcp/cloudflare/.env enthält bisher weder CF_ACCESS_CLIENT_ID noch _SECRET — es ist nichts halb erledigt. 🔴 Das Secret wird nur bei der Rotation ausgegeben, wer es nicht sofort schreibt, muss erneut rotieren. Abnahme = ein Aufruf mit den Headern (antwortet) und einer ohne (403) — der Erfolgsfall allein beweist nichts, der Hostname könnte auf bypass stehen.

TP16 — CF-Tunnel: Round-Robin killen + reziprokes HA ▸ ✅ HA WIEDER VOLL (2026-08-24) — Kern 2026-07-10 — docs/cf-tunnel-mapping.md §10 + §15, #1033

• ✅ GEFIXT 2026-08-24 — Ursache war ein docker stop, kein QUIC-Flap. Die beiden macmini-Connectoren (cloudflared-bfnas, cloudflared-bfpve) standen auf Exited (0), beide finishedAt auf derselben Sekunde 2026-07-21T13:00:53, bei korrekt gesetztem restart=unless-stopped und http2. Fix = docker start der zwei, sonst nichts. Abnahme: alle drei bf-Tunnel je 2 Connectoren / 8 conns, und 36 Anfragen über 6 FQDNs beider betroffener Tunnel mit 530er = 0. Details §15.
  • 🔴 Die Datierung im Befund unten war falsch: degradiert seit 2026-07-21, nicht seit dem 08-16 — der 08-16 war der Tag der Entdeckung. Vier Wochen unbemerkt.
  • 🔴 Die eigentliche Lehre ist die Nachweislücke: ein Tunnel mit 1 von 2 Connectoren meldet healthy. Über den Tunnel-Status ist die Degradation unsichtbar, nur die Connector-Anzahl zeigt sie. ⇒ Check nach TP11: connectoren < 2 je bf-Tunnel = Alarm. Ein HA-Design ohne Zähler auf die Redundanz ist kein HA-Design.
• 📜 Ursprünglicher Befund 2026-08-16 (Historie, Ursache s.o.):
  • bf-mm = 2 Connectoren (je 4 conns) ✅ · bf-nas = 1 Connector (3 conns) 🟠 · bf-pve = 1 Connector (4 conns) 🟠.
  • Bedeutung: die Dienste hinter bf-nas (gitea, grafana, pve-mcp, vw, ds-bf, nautobot) und bf-pve (pve, ccu, iobroker, z2m25, portainer, hass, ha-mcp) hängen jeweils an einem einzigen cloudflared-Prozess. Fällt dessen Host aus, sind sie weg — genau der Zustand, den TP16 beseitigt hat. Kein 530/Round-Robin-Problem (das bleibt strukturell gelöst), sondern Redundanzverlust.
  • Bekanntes Muster: identisch zum Incident vom 2026-07-16 🔴 war es NICHT — s. Fix oben. Ursprungstext: Bekanntes Muster: identisch zum Incident vom 2026-07-16 (macmini-Connectoren flappten unter QUIC → Fix TUNNEL_TRANSPORT_PROTOCOL=http2). Diesmal sind die macmini-Connectoren oben (bf-mm hat 2), es fehlt je ein Gegenstück auf NAS/pve. Nächster Schritt (eigene Session): auf NAS und pve nachsehen, welcher der beiden cloudflared-Container nicht läuft, und ob es der http2-Konventionsfall ist.
• ✅ GELÖSCHT 2026-08-24 (User-Entscheid „alle vier"): openclaw, coolify, johnny2, TeilzeitCharlie sind über die CF-API entfernt, alle vier mit success: true. Gegenprobe: 5 Tunnel verbleiben (bf-mm/bf-nas/bf-pve je 2 Connectoren, fm und terpene-db je 1 — beide standortfremd bzw. eigenes Projekt, kein Defekt). Damit sind auch die letzten VLAN1-Origins (10.40.41.147/.148/.139/.133) aus der Cloudflare-Config verschwunden — der Rest von TP19.
• 📜 Ursprünglicher Nebenbefund (Historie): Alt-Tunnel mit VLAN1-Origins (alle down, 0 Connectoren, daher aktuell harmlos):** openclaw (→ 10.40.41.147/.148/.139), coolify (→ 10.40.41.133), johnny2, TeilzeitCharlie. ⚠️ openclaw beansprucht n8n.emsenhuber.net, das produktiv auf bf-mm läuft — käme der Tunnel je wieder hoch, entstünde exakt das alte Round-Robin-Muster auf diesem Hostname. Empfehlung: die vier toten Tunnel löschen (user-gated, Löschen ist nicht umkehrbar) 🔵 Begründung korrigiert 2026-08-24: die Sorge „käme der Tunnel wieder hoch, entstünde das alte Round-Robin auf diesem Hostname" ist so nicht richtig — welcher Tunnel einen Hostname bedient, entscheidet das DNS, und live zeigt kein einziger CNAME auf die vier (n8n zeigt korrekt auf bf-mm). Ein hochkommender openclaw wäre inert. Der reale Pfad ist ein aktives cloudflared tunnel route dns, das den CNAME umschreibt. ⇒ Löschen bleibt richtig — als Hygiene und um genau diese Falle zu entfernen, nicht als Störungsbehebung. — gehört fachlich zu TP19 (VLAN1-Retirement: .41.133 war eines der „unidentifizierten VLAN1-Geräte" aus TP19 B1.2 — hiermit als coolify-Origin identifiziert).

✅ Umgesetzt (2026-07-10, eigene Session): reziprokes 3-Tunnel-HA live (bf-nas 70d6a4cf / bf-pve f7fdf3a6 / bf-mm 7a322261), 6 Connectoren (2/Host, je Fremdhost), 19 FQDNs Loop-Smoke 0×530, HA per Host-Ausfall-Sim bewiesen. Round-Robin-#1033 strukturell weg. As-Built = docs/cf-tunnel-mapping.md §10. Schritt 5 Access-Strang: vw bypass→geschützt via WARP — 🔴 GESTRICHEN (User-Constraint 2026-08-14, s. TP16.2). Verbleibend offen: hass/ha-mcp 400/403; gateway-dw (WG→404) klären.

• Symptom (User): FQDNs über CF werden sporadisch / „sehr unsicher" aufgelöst = #1033-Muster zurück („jeden 3. Schuss eine Niete"). User hat alle 3 cloudflared-Images + Container aktualisiert/neu gestartet.

• ✅ Root-Cause endgültig (User-Diagnose bestätigt): macvlan/ipvlan-Host-Isolation. Ein cloudflared-Connector ist blind für macvlan/ipvlan-Container auf seinem EIGENEN Host (Linux-Kernel-Regel), erreicht aber Fremdhost-L2 + co-lokierte Bridge-Container. Mehrere Connectoren auf EINEM Tunnel = geteilter Ingress + CF-Round-Robin → jede Origin, die auf dem Host eines Connectors liegt, fällt bei ~1/N aus. Strukturell, nicht durch „Origins fixen" heilbar. Bsp: omada .20.175/pve-mcp .20.173/gitea .20.157/grafana .20.109 = NAS-macvlan → vom NAS-Connector NICHT erreichbar.

• Invariante: innerhalb EINES Tunnels ist kein Route→Connector-Pinning möglich (alle Connectoren teilen Ingress, CF round-robined). „Ausgewählte Routen für ausgewählte Connectoren" = getrennte Tunnel.

• Ziel-Design (HA): reziproke Per-Host-Tunnel — jeder Host-Dienst wird von den Connectoren der ANDEREN Hosts bedient (nie vom eigenen):

  Tunnel (= Dienste eines Hosts)	Connectoren auf	HA
  pve-Dienste	NAS + macmini	1 abdrehbar
  NAS-Dienste (omada/pve-mcp/gitea/grafana/…)	pve + macmini	1 abdrehbar
  macmini-Dienste (.20.167)	pve + NAS	1 abdrehbar

  3 Tunnel, jeder Host fährt 2 cloudflared → Host-Ausfall ⇒ jeder Tunnel ≥1 Connector = voll HA. Voraussetzung: jede Origin L2-erreichbar.

• Ist-Inventory (live 2026-07-10, s. cf-tunnel-mapping.md §9): Ingress v119, 24 Hostnames, 2 live Connectoren. DOWN/stale: pbs .20.135, nginx-bf .41.123 (noch VLAN1!), hermes+hermes-geli .20.167. Zu klären (Host/Netz): vw .20.127/ccu .20.232/iobroker .20.107/z2m25 .20.106 — ggf. vw/ccu auf VLAN20-macvlan heben. gateway-dw (192.168.178.1) = WG-Sonderfall.

• CF-Access-Strang (verzahnt, s. TP11 Track-B): hass-400 in der HA-iPhone-App = CF-Access davor (Companion-App kann Access-Login nicht) → Fix ohne Passthrough: iPhone in WARP enrollen (Device-Identity erfüllt Access; „Warp Login App" existiert bereits allow:christoph). ⚠️ vw = aktuell bypass (öffentlich!) → von bypass auf geschützt heben. 🔴 Überholt (2026-08-14): vw BLEIBT bypass — harter User-Constraint, Härtung stattdessen über TP16.2. „Passthrough-Hosts sind die kritischen" (User).

• Umsetzungs-Reihenfolge (für die eigene Session): (1) Reachability-Matrix je Host (pve/NAS/macmini → jede Origin, read-only) BEVOR gruppiert wird; (2) Interim-Sofortfix: bf-Tunnel auf pve-only (pve erreicht alles außer gateway-dw) → 0×1033, reversibel; (3) reziprokes 3-Tunnel-HA bauen (CNAMEs re-pointen, 6 Connectoren, Token je Tunnel; NAS/macmini-Alt-Token entfernen); (4) tote Origins bereinigen; (5) Access-Strang (WARP + vw); (6) Loop-Gegentest.

• Abh.: TP14.1/14.2 ✅. Verwandt: TP11 (CF-Tunnel-Track-B/C + Access), #1033. SSoT: docs/cf-tunnel-mapping.md. Memory project_cf_tunnel_1033.

• ✅ Incident 2026-07-16 (User unterwegs, WARP „spinnt", keine BF-IPs mehr) ▸ Public-FQDN-Teil gefixt: macmini-Connectoren (cloudflared-bfnas/-bfpve) flappten live unter QUIC/UDP (Docker-Desktop-Bridge-NAT) → bf-nas/bf-pve von 2 auf 1 Connector degradiert (HA faktisch weg, nicht down). Fix: beide auf TUNNEL_TRANSPORT_PROTOCOL=http2 umgestellt (rollend, 0 Downtime), wieder voll HA. Konvention: macmini-Connectoren künftig immer http2. ICMP-Befund (getrennt, strukturell): TCP über die WARP-Route ging überall, ICMP nicht (fm 36 %/bf 100 %/dw 100 % Loss) — cloudflared ist QUIC-Proxy, kein WireGuard. Kurz als „bf-pve-Route wegen USV" notiert (Commit 1c1a676) → REVIDIERT (Begründung invertiert: bf-pve-Connectoren laufen auf NAS+macmini, nicht pve). Details: docs/cf-tunnel-mapping.md §13. → Richtungswechsel für Private Access = TP16.1.

TP16.2 — Härtung der öffentlich erreichbaren Dienste (bypass-Strang) ▸ 📋 KONZEPT (2026-08-14), Umsetzung offen

• 🔴 HARTER CONSTRAINT (User 2026-08-14): vw wird NICHT WARP-/Access-geschützt. Gilt dauerhaft, nicht „vorerst". Begründung (technisch belastbar, nicht Bequemlichkeit): die Bitwarden-Clients (Browser-Extension, Mobile, Desktop) können den interaktiven Access-Login nicht durchführen — dasselbe Muster, das die HA-Companion-App auf 400 laufen lässt. Ein Passwortmanager hinter einem Client, den man im Notfall (fremdes Gerät, Neuinstallation, Handyverlust) nicht installieren kann, ist ein Aussperr-Risiko gegen den eigenen Schlüsselbund — und damit gefährlicher als das, wovor die Maßnahme schützen soll. Die frühere TP16-Schritt-5-Absicht „vw von bypass auf geschützt heben" ist damit gestrichen.
• Ziel stattdessen: Schutz erhöhen, ohne Clients zu brechen — gilt für alle bypass-Dienste (vw, hass, gitea).
• ✅ Schicht 0 — bereits vorhanden, nicht unterschätzen: keine offenen Ports, alles ausschließlich über CF-Tunnel (3-Tunnel-HA, TP16), TLS terminiert an der Edge, DDoS-Schutz. Der Origin ist nicht direkt erreichbar. Das ist bereits mehr als bei den meisten Selfhostern.
• ✅ Schicht 1 — chirurgisch: Access nur auf die Pfade, die kein Client anfasst. CF Access wertet die spezifischere Application zuerst → man kann eine zweite Access-App auf vw.emsenhuber.net/admin* legen (echte Policy) und den Host im Übrigen auf bypass lassen. Das Admin-Panel wird ausschließlich per Browser bedient — dort funktioniert der Access-Login einwandfrei, während /api, /identity und /notifications (die Client-Pfade) unberührt bleiben. Kein Client bricht, das wertvollste Ziel ist weg.
  • Alternativ noch härter: Admin-Panel ganz aus (ADMIN_TOKEN leer lassen) und nur bei Bedarf temporär aktivieren.
  • Analog für gitea: /admin* + Registrierung path-scoped schützen (Git-über-HTTPS mit Token bleibt offen).
• ✅ Schicht 2 — App-eigene Bremsen (kostenlos, sofort): Vaultwarden hat Rate-Limits per Default an (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10, dazu ADMIN_RATELIMIT_*) → Werte prüfen/verschärfen; SIGNUPS_ALLOWED=false, INVITATIONS_ALLOWED=false, SHOW_PASSWORD_HINT=false, 2FA erzwingen. HA hat ip_ban_enabled + login_attempts_threshold. Gitea: Registrierung aus.
• ✅ Schicht 3 — Edge-Regeln (CF), wirkt für alle Dienste gemeinsam: WAF-Custom-Rules + Rate Limiting gezielt auf die Login-Endpunkte (/identity/connect/token bei vw, /auth/login bei HA, /user/login bei Gitea); optional Geo-/ASN-Filter. ⚠️ Free-Plan-Kontingente vorher im Dashboard prüfen (nicht belegt).
• ✅ Schicht 4 — ein Mechanismus für alle: CrowdSec (oder fail2ban) mit Cloudflare-Bouncer. Bans landen dann an der Edge statt erst am Origin. Vaultwarden hat ein offizielles Fail2Ban-Setup-Wiki (Log-Muster für Login und Admin-Panel).
• 🔴 Voraussetzung für Schicht 2–4, und der eigentliche Knackpunkt: die echte Client-IP muss am Origin ankommen. Hinter dem CF-Tunnel sieht die Anwendung sonst nur die IP des cloudflared-Containers → jede IP-Sperre bannt den Tunnel statt den Angreifer = Selbstaussperrung aller Nutzer, und Rate-Limits greifen ins Leere. Genau dieser Defekt ist bereits offen dokumentiert: HAs trusted_proxies fehlen .20.10/.20.167 (TP16, hass-400-Strang). ➡️ X-Forwarded-For/CF-Connecting-IP sauber durchreichen ist Schritt 1 dieses TPs, alles andere baut darauf auf.
• Reihenfolge: (1) Client-IP-Weitergabe fixen (inkl. HA trusted_proxies) → (2) /admin-Pfade path-scoped schützen → (3) App-Limits + 2FA → (4) Edge-Rules → (5) CrowdSec/fail2ban mit CF-Bouncer.
• Abh.: TP16 ✅ (Tunnel-HA). Verwandt: TP20.1 (vw wandert auf Platform-Postgres — DB-HA ≠ Access, getrennt halten), TP23 (dessen WARP-Managed-Network-Idee ist durch diesen Constraint entlastet: vw verlangt keine Device-Identity, also kollidiert „WARP zuhause aus" nicht mehr mit dem Access-Strang).

TP16.3 — cloudflared-Reduktion: was der Mesh als Datenpfad kann (und was nicht) ▸ ⏳ PROBE LÄUFT SEIT 2026-08-24 — docs/tp16.3-nautobot-mesh-only-runbook.md §8

• ▶️ Schnitt ausgeführt 2026-08-24: nautobot.emsenhuber.net ist aus dem Ingress von bf-nas entfernt (8 → 7 Regeln, Catch-all weiterhin letzte). Rollback-Sicherung liegt unter docs/cf-backup/bf-nas-ingress-20260824-vor-tp16.3.json — Rückweg ist ein PUT, eine Minute. Abnahme vollständig: private IP mit WARP von außerhalb des LAN 302 in 0,16 s · die übrigen fünf bf-nas-Hostnames unverändert · und der Punkt, den man übersieht — Golden Config lief durch: Backup → Intended → Compliance, 104/104, 0 Drifts.
  • 🎯 Der Testaufbau war der einzige, der etwas beweist: die Session lief auf einem Host im Hotspot-Netz 172.20.10.13 mit aktivem WARP, also nicht im BF-LAN. Aus dem LAN heraus wäre der Zugriff ohnehin gegangen und hätte nichts gezeigt (Merkregel feedback_adresse_lesen_nicht_ansagen).
  • 🔴 Befund, der die Abnahmetabelle des Runbooks korrigiert: der öffentliche FQDN taugt nicht als Test. nautobot.emsenhuber.net liefert vor und nach dem Schnitt HTTP 302 — der kommt von Cloudflare Access, nicht vom Origin (location: emsenhuber.cloudflareaccess.com/cdn-cgi/access/…, JWT auth_status: NONE bei is_warp: true). Access greift vor dem Tunnel. ⇒ Gültiger Nachweis ist das Zurücklesen der Ingress-Config, nicht die Antwort des Frontends — dieselbe TP22/TP23-Regel.
  • 📌 Und die Erwartung wird damit ehrlicher: Nautobot war nie ohne Access-Login öffentlich erreichbar. Der Schnitt schließt keine offene Tür, er entfernt eine überflüssige zweite.
  • ⚠️ Vorprüfung, die vor jedem weiteren Schnitt zu wiederholen ist: hängt Werkzeug am öffentlichen Namen? Hier nein — gc-configplan.py spricht http://10.40.20.30:8080/api, und kein Repo-Skript nutzt den FQDN.
• ⏳ Offen: das Betriebsfenster. Eine Woche fahren (bis ~2026-08-31), dann entscheiden, ob es so bleibt und ob pve/portainer/grafana/pve-mcp/ha-mcp/gitea-mcp/ds-bf/ccu/iobroker/z2m25 folgen.
• 📌 Ein Argument des TP ist entfallen: die HA-Degradierung, die §7 als Nebeneffekt anführte, ist am selben Tag repariert (TP16 ✅). Der Fall steht damit allein auf dem eigentlichen Argument — weniger bewegliche Teile für Dienste, die öffentlich nicht gebraucht werden.

📌 Der Schnitt (nautobot aus dem bf-nas-Ingress) ist ausformuliert inkl. Vorbedingungen, PUT-Ablauf und Rollback. Zwei Punkte stehen dort explizit, weil sie den TP sonst kippen: Mesh-Hostname-Routes sind Egress und veröffentlichen nichts (wer das verwechselt, baut den Public-Strang ab), und Nautobot ist nicht nur Web-UI, sondern die Deploy-Pipeline → zur Abnahme gehört ein Job-Lauf, nicht nur ein Browser-Aufruf. Christophs Frage (2026-08-17): „recherchiere, ob unser neuer wg-tunnel/cf mesh als datenpfad für die server/services genutzt werden kann. die containerpflicht als offizieller weg ist für mich unlogisch."

• ✅ Die Container-„Pflicht" gibt es für den privaten Zugang tatsächlich nicht — und wir nutzen sie schon nicht mehr. CF-Docs (Mesh↔Tunnel-Vergleichstabelle) sind eindeutig: Mesh = bidirektional, L3/L4, TCP+UDP+ICMP, jeder Teilnehmer bekommt eine Mesh-IP, Connector = warp-cli oder ein nativer WireGuard-Peer (unser Fall). Tunnel = inbound zum Origin, Veröffentlichen von Hostnames, Connector = cloudflared, Protokolle HTTP/S·TCP·SSH·RDP·SMB über WebSocket geproxied. Für „Server hinter dem Node erreichbar machen, die keinen Client laufen lassen können" nennen die Docs ausdrücklich CIDR-Routes auf dem Mesh-Node als den Weg — wörtlich für „servers, databases, printers, IoT devices".
• 🎯 Das ist bei uns seit TP16.1 bereits scharf: die vnet-Route 10.40.0.0/16 zeigt auf bf-core-mesh (§4.4, Weg A). Der gesamte private Datenpfad läuft schon über natives WireGuard auf dem Core, ohne jeden Container. Und er ist im TP5-Log-Lauf belegt, nicht vermutet: 137 Zeilen in:cf-mesh, Quelle 100.96.0.1 → Nautobot .20.30:8080 (62×), NAS .20.10:6690 (46×), macmini :22, NAS :5000/:5001/:443/:22, pve .20.100:8006, pve-mcp .20.173:3000, branch/ap1/ap2 :22. Christophs Instinkt war richtig.
• 🔴 Wo die Container-Pflicht echt ist — und warum sie nicht willkürlich ist: für einen öffentlichen Hostname, den jemand ohne WARP im Browser aufruft, braucht es einen Reverse-Proxy an der Edge. Das ist cloudflared. Achtung Verwechslungsfalle: Mesh kennt seit 2026-07-02 ebenfalls Hostname-Routes, und die können auch public hostnames — aber das ist Egress: „route that hostname's traffic through the node and egress via the node's public IP". Es veröffentlicht nichts. Wer das verwechselt, baut den Public-Strang ab und ist überrascht.
• ✅ Der reale Gewinn ist trotzdem groß, weil die meisten Dienste keinen öffentlichen Hostname brauchen. Kriterium: hat der Dienst einen Client, der keinen interaktiven Access-Login kann? (dieselbe Logik wie der TP16.2-Constraint bei vw)

  Muss öffentlich bleiben (cloudflared)	Grund	Kann auf Mesh-only
  vw	Bitwarden-Clients, harter TP16.2-Constraint	pve, nautobot, portainer, grafana
  hass	Companion-App (400-Muster)	pve-mcp, ha-mcp, gitea-mcp, ds-bf
  n8n	eingehende Webhooks von Dritten	ccu, iobroker, z2m25
  gitea	Git-Clients / CI von außen — zu prüfen
  → Für die rechte Spalte ist der Mesh funktional gleichwertig und operativ einfacher (keine Ingress-Zeile,
  kein Connector-Paar, keine HA-Frage). Sie erreicht man ohnehin schon per privater IP.

• 📌 Zwei Nebeneffekte, die den Fall stärken: (1) die TP16-HA-Degradierung (bf-nas/bf-pve je nur ein Connector) verliert an Gewicht, sobald nur noch die vier Public-Dienste an cloudflared hängen — weniger Dienste pro SPOF; (2) ICMP + beliebiges UDP gehen über den Mesh und über cloudflared grundsätzlich nicht (der QUIC-Proxy war genau die Lücke aus TP16.1).
• ⚠️ Grenzen, ehrlich benannt: (a) der Mesh-Weg setzt WARP auf dem Client voraus — für Christophs eigene Geräte gegeben, für Gäste/Fremdgeräte nicht; (b) IPv6-CIDR-Routes brauchen MASQUE und funktionieren mit einem WireGuard-Device-Profil nicht — deckt sich mit dem v4-only-Entscheid aus TP16.1, wäre aber ein Blocker, falls TP12 später v6 über den Mesh wollte; (c) es bleibt eine Cloudflare-Abhängigkeit — der Mesh ersetzt cloudflared, nicht Cloudflare.
• Vorgeschlagener Umsetzungsschnitt (klein anfangen, reversibel): einen Dienst der rechten Spalte als Probe aus dem CF-Ingress nehmen (Kandidat: nautobot — nur Christoph nutzt es, im Mesh-Log mit 62 Treffern der am häufigsten per Mesh angefasste Dienst, und ein Fehlschlag kostet nichts Produktives), eine Woche fahren, dann entscheiden. Rollback = eine Ingress-Zeile zurück.
• 📋 Runbook: docs/tp16.3-nautobot-mesh-only-runbook.md (2026-08-19) — der Schnitt oben, ausführbar ausformuliert: Vorbedingungen (Mesh-Route, Zugriff über 10.40.20.30:8080 mit WARP von außerhalb), Ingress-PUT über CF_API_TOKEN (nicht über den CF-MCP, der ist read-only), Rollback aus der gesicherten Config.
  • 🔴 Der Abnahmepunkt, den man übersieht: Nautobot ist nicht nur Web-UI, sondern die Deploy-Pipeline. Nach dem Schnitt gehört ein Job-Lauf zur Abnahme, nicht nur ein Browser-Aufruf — der Netmiko-Deploy kommt von 10.40.20.31 (nautobot-worker), nicht von .20.30.
  • ⚠️ Beim Kürzen des ingress-Arrays muss die Catch-all-Regel die letzte bleiben, sonst greift der Ingress für alle übrigen Hostnames nicht mehr.
• Abh.: TP16.1 ✅ (Mesh live), TP16 (Public-Strang + dessen HA-Degradierung), TP16.2 (der vw-Constraint liefert das Entscheidungskriterium). ⚠️ Berührt TP5: der Mesh-Verkehr braucht bei deny-by-default eine explizite forward-Zeile — s. TP5 Etappe 2.

TP17.1 — Shelly Gen4 raus aus dem WLAN ▸ ❌ VERWORFEN (2026-08-23) — Weg bewiesen, Ziel damit nicht erreichbar — 📋 docs/tp17.1-shelly-gen4-funkmigration-runbook.md

❌ User-Entscheid 2026-08-23 nach dem Pilot: stoppen und zurückbauen. Auslöser war Christophs strukturelle Frage: „zigbee sollte die antwort auf die vielen radios auf -iot geben. nutzt aber wenig wenn man das wifi nicht abdrehen kann bzw. es nicht mehr aktivieren kann ohne reset."

Der Pilot hat den Weg technisch vollständig bewiesen — s9 lief auf PowerStripZB, trat ZHA bei, ein Zigbee-Befehl schaltete das physische Relais, kein Broadcast-Sturm. Und er hat gezeigt, dass das Ziel so nicht erreichbar ist:

• Das Gerät bleibt WLAN-Client — Zigbee kommt zusätzlich, nicht statt.
• Der Funkgewinn ist gemessen klein: die 12 Gen4 sind 12 von 26 IoT-Clients, bewegen aber je nur ~150–200 KB rx / 0,6–3 MB tx in sechs Stunden. Leerlaufende Stationen.
• Der Preis wäre dauerhaft: die Zigbee-Firmware hat keinen AP (WiFi.GetConfig kennt nur sta/sta1/roam), Shelly macht kein Zigbee-OTA, und Shelly.InstallAlt braucht IP. WLAN aus hieße: nie wieder Firmware-Update, kein Rückweg — bei 10 Unterputz-Modulen.

✅ Rückbau durchgeführt 2026-08-23: ZHA-Knoten sauber entfernt (Leave vor dem Flash, damit kein Geisterrouter im 52-Geräte-Mesh bleibt), s9 zurück auf PowerStrip, Config aus dem Backup wiederhergestellt. Compliance des Zigbee-Netzes unauffällig: alle vier roten EZSP-Zähler blieben 0, Retry-Quote fiel im Delta auf 8,9 %. ⚠️ Beim Rückflash zog die Firmware einen OFFENEN AP hoch (ap.enable=true, is_open=true) — abgeschaltet und mit dem IoT-PSK abgesichert. Nach jedem Shelly-Firmwarewechsel den AP prüfen.

📌 Das Runbook bleibt — es enthält den kartierten Mechanismus (drei undokumentierte RPCs, Zwei-Slot-Modell), das gemessene 2,4-GHz-Bild und die ZHA-Sturmzähler mit Baseline. Der Weg ist nicht gescheitert, das Ziel war mit ihm nicht erreichbar. 🔭 Einziger Restposten: der Frühindikator — Shelly.CheckForUpdate auf einem Gen4 auf einen …MT/Thread-alt-Eintrag beobachten. Erscheint er, ändert sich die Rechnung.

Ursprünglicher Planungstext (historisch)

User-Formulierung (2026-08-23): „wir lassen das pwd vorerst wie es ist. wir werden alle shelly gen4 auf thread umstellen — neue firmware. das machen wir im ha-projekt. das sehe ich als subpunkt zu pwd ändern. der vorteil: wir müssen dann weit weniger geräte umstellen, steigern thread-stabilität und bringen zudem mehr ruhe ins wifi."

📋 Runbook: tp17.1-shelly-gen4-funkmigration-runbook.md — Bestand, die drei Wege im Vergleich, Ablauf, Abnahme, Verzahnung mit der PSK-Rotation. 📌 Wohnort ist das Netz-Projekt (User-Entscheid 2026-08-23). Eine erste Fassung lag kurz im HA-Projekt (ha-xstate); sie ist dort entfernt, damit es keine zweite Wahrheit gibt. HA ist Betroffener, nicht Eigentümer: die Entities brechen, aber die Entscheidung ist eine Funk- und Netzentscheidung. (Der Titel sagt jetzt „Thread oder Zigbee" — der ursprüngliche Thread-Zuschnitt hat den heute tatsächlich verfügbaren Weg ausgeschlossen, s. Nachtrag unten.)

• 🔀 Die Reihenfolge ist der eigentliche Entscheid: die PSK-Rotation (Follow-up unten) wird nachgelagert, nicht vorgezogen. Begründung des Users: jedes Gerät, das vorher auf Thread wandert, muss beim PSK-Wechsel nicht mehr angefasst werden. Damit ist die Rotation Nachfolger von TP17.1, nicht mehr eigenständig. (Sie war nie dringend — Anlass war ein Passwort in einem Sitzungstranskript, kein Vorfall.)
• 📊 Bestand live gesweept 2026-08-23 (mcp/shelly/discover.py, read-only, VLAN30): 22 von 26 erreichbar, davon 12 Gen4 (9× 2PM Gen4 S4SW-002P16EU, 1× 1PM Gen4, 2× Plug S Gen4), 8 Gen3, 2 Gen2 — alle auf Firmware 2.0.0. Nicht erreichbar: s1/s2/s3 (weihnachten_*, saisonal) und s4 kueche_mikrowelle (Metallgehäuse, RSSI −93 — der Härtefall des WLAN-Betriebs).
• 🔴 Die Prämisse „neue Firmware" trägt so nicht, und das ändert die Rechnung: Shelly unterstützt Matter over Thread offiziell nicht und plant es nicht. Gen4 kann offiziell nur Matter over WiFi — was hier nutzlos wäre, weil das Gerät im WLAN bliebe und den PSK weiter bräuchte. Thread geht nur über Dritt-Firmware (die ESP32-C6-Hardware kann es). Das brauchbare Projekt (hencou/shelly_gen4_matter_module) deckt 1/1 Mini/1PM/2PM Gen4 ab = 10 der 12 Geräte; die zwei Plug S Gen4 fallen raus. Preis: Garantie und Shelly-Cloud weg, Rückweg nur mit UART-Vollbackup je Gerät, PM-Kalibrierung zunächst Platzhalter. ⇒ Selbst bei vollem Erfolg blieben 12 Shellys im WLAN (8 Gen3 + 2 Gen2 + 2 Plug S + die 4 ausgesteckten). Die Rotation wird kleiner, nicht überflüssig — und Gen3 kann nie folgen, dort fehlt 802.15.4. Das ist Christophs Abwägung vor dem ersten Flash, nicht die des Umsetzenden.
  • 📊 Und die Rechnung ist noch etwas ungünstiger, als „Shellys" nahelegt (live 2026-08-23): auf dirtyvader-iot hängen 26 der 27 WLAN-Clients des ganzen Netzes — darunter Drucker (P750W), Airfryer, SwitchBot, Twinkly, DTUBI und ein SONOFF-NSPanelPro, die von Thread nichts haben. Nach zehn migrierten Gen4 blieben also grob 16 Geräte auf dem IoT-SSID, nicht 12. Der WLAN-Ruhe-Effekt ist real (−38 % Clients), der PSK-Effekt ist es halb.
• ✅ Was netzseitig schon steht und nicht nochmal gebaut werden muss: Thread-Border-Router läuft mit ~30 produktiven Matter-Knoten; der Commissioning-Weg ist erprobt — temporäre SSID dirtyvader-infra (VLAN20) nach matter-pairing-infra-ssid-runbook.md, am 2026-08-22 mit dem TIMMERFLOTTE bewiesen. cfg-infra/dp-infra/sec-infra stehen dauerhaft am Manager, das Anlernen ist ein Zweizeiler plus eine Config-Transaktion.
• 🔴 Der Umweg bleibt nötig, weil TP12.1 offen ist (kein IPv6-Routing VLAN10↔VLAN20 → Matter- Commissioning-Etappe 2 bricht ab), und ble_proxy ist wirkungslos, seit der ESP32-BT-Proxy ausgeschlossen wurde. Je mehr Thread-Geräte kommen, desto öfter zahlt man diesen Umweg — das ist das stärkste neue Argument für TP12.1, das bisher nur an einem einzigen Fühler hing.
• Abnahme (aus TP28 gelernt): pro Gerät ein frischer Thread-Knoten und eine funktionierende HA-Entity — nicht die Anzeige in einer Tabelle. Ein Gerät, das in Thread hängt und in HA halbtot ist, ist ein Rückschritt.
• 🔬 Nachtrag 2026-08-23 (abends) — die Geräte selbst befragt (Shelly.CheckForUpdate, read-only). Ergebnis: es gibt heute KEIN Thread-Update, aber die offizielle Alt-Firmware-Schiene existiert — sie liefert bisher ZIGBEE.

  Was	Stand am Gerät
  Stable	2.0.0 auf allen 22 — für keines ein stabiles Update verfügbar
  Beta	2.0.1-beta1 (Build 2026-08-19) für alle, auch Gen3
  Alt-Varianten (nur Gen4!)	S2PMG4ZB „Shelly 2 PM Gen4 with Zigbee" · S1PMG4ZB (1 PM Gen4) · PowerStripZB (Power Strip Gen4) — je stable 2.0.0 + beta
  Gen3 (S3PL-*)	kein alt-Eintrag → Alternativfunk ist eine reine Gen4-Sache, wie erwartet

  • 🎯 Das ist die wichtigste Erkenntnis für die Planung: Shelly liefert alternative Funk-Firmware für Gen4 über den normalen Update-Kanal, nicht über einen Bastelpfad. Käme eine Thread/Matter-Variante, erschiene sie mit hoher Wahrscheinlichkeit genau dort als weiterer alt-Eintrag. ⇒ Billiger Frühindikator statt Warten auf Pressemeldungen: Shelly.CheckForUpdate auf einem Gen4 pollen und auf einen …MT/Thread-Eintrag warten.
  • 📰 Presselage (recherchiert 08-23): Shellys offizielle Linie ist „wird evaluiert", nicht „ist angekündigt" — Stand Juli 2026, mit Flash-Platz als genanntem Engpass. Ein Release-Datum gibt es nicht. (Die Thread-Firmware, die im Mai 2026 als „für Gen4 verfügbar" durch die Presse ging, ist die Dritt-Firmware von automatous-io, nicht Shelly.)
  • 💡 Und daraus folgt eine Option, die vorher nicht auf dem Tisch lag: ZIGBEE statt Thread. Sie erfüllt alle drei Ziele von TP17.1 — Geräte raus aus dem WLAN (PSK-Rotation wird billiger), Mesh-Stabilität, Funkruhe im 2,4-GHz-WLAN — und zwar heute, mit Hersteller-Firmware über den offiziellen Kanal, also ohne Garantieverlust, ohne UART-Backup, ohne Test-VID. Die Infrastruktur steht bereits: Zigbee2MQTT läuft als LXC 112 (10.40.20.106, z2m25). ⚠️ Zu prüfen, bevor das zur Empfehlung wird: (a) ob die Alt-Firmware genauso zurückrollbar ist wie ein normales Update (Wechsel des Funkstacks, nicht nur der Version) — offen; (b) der Entity-Bruch ✅ entschärft (User 2026-08-23): der Umbau behält die Entity-Namen — damit fällt der teuerste Posten der Abwägung weg, für Zigbee und Thread gleichermaßen (zwei Fallen dazu im Runbook: die alte entity_id ist erst nach dem Entfernen frei, und unique_id/Statistiken sind trotzdem neu); (c) Kanalplanung ✅ erhoben 2026-08-23 — es gibt drei 802.15.4-Netze, nicht eines: Thread 15 (~30 Matter-Knoten), ZHA 20 (52 Geräte, SONOFF Dongle-M über socket://10.40.30.137:6638), Z2M 25 (Sonoff Dongle Plus). Gegen WLAN ap1 ch1 / ap2 ch11 ist das sauber — außer ZHA ch20 (2450), das direkt auf der Unterkante von WLAN ch11 (2451) sitzt, ausgerechnet 52 Geräte gegen den AP mit 26 Clients. Die Lücke 2423–2451 (ZB 16/17/18) ist unbenutzt; ⚠️ ein ZHA-Kanalwechsel müsste von 52 Geräten mitgemacht werden, schlafende und ältere Router folgen nicht zuverlässig → erst Energy-Scan, dann entscheiden. 🔴 Und der Vorbehalt, der schwerer wiegt als alle drei: Christophs Z2M-Vorfall von 2024 („Lichterdisko", Installation unsteuerbar, Neuaufbau). Fehlerklasse ist benennbar (Broadcast-/Routing-Sturm — trifft ZHA genauso), Root Cause nicht mehr rekonstruierbar. ⇒ Mitigation ohne Ursachenkenntnis = Blast Radius trennen: die zehn neuen Router komplett in ein Zigbee-Netz, und zwar in das, das nicht Licht und Fernbedienungen trägt. Details und Abbruchkriterium im Runbook.
• 🩺 HA-Gegencheck 2026-08-23: genau EIN Shelly ist offline — s4 kueche_mikrowelle (23 Entities unavailable). Deckungsgleich mit dem Netz-Sweep, und es ist dasselbe Gerät, das bei RSSI −93 hinter Metall hängt. s1/s2/s3 (weihnachten_*) sind in HA nur DEAKTIVIERT, nicht gelöscht (Christoph 2026-08-23) — deaktivierte Entities haben keinen Zustand und tauchen deshalb in keiner Zustandssuche auf. Die Entities gibt es also zu Recht; sie kommen mit den Geräten zurück. (Meine erste Formulierung „existieren gar nicht" war falsch.) ⇒ Für die PSK-Rotation heißt das: drei Geräte, die niemand vermisst, aber die beim nächsten Einstecken mit dem alten PSK kommen. Genau dafür ist die Übergangs-access-list da.
• 🖨️ Es gibt ZWEI Drucker — geklärt 2026-08-23, beide Angaben waren richtig: (1) P750W = Etikettendrucker, VLAN30 (10.40.30.5, Reservierung auf dhcp-v30, ARP vlan30; am 08-23 aus, last-seen 3d15h — deshalb nicht unter den 26 assoziierten Clients). (2) Brother MFC = der eigentliche Drucker, VLAN10 — live bestätigt 10.40.10.6, MAC 30:05:5C:78:86:20 (OUI Brother Industries), ARP delay = aktiv, statisch konfiguriert, keine DHCP-Reservierung. 📌 Folge für TP5: die Merkregel „Drucker fällt mit udp/161 (SNMP) aus, nicht mit 631" (ref_printer_snmp_before_ipp) gilt dem VLAN-übergreifenden Fall. Der MFC steht im selben VLAN wie die Macs — dort greift die forward-Kette gar nicht.
• 🔀 Reihenfolge revidiert (User 2026-08-23): PSK-Rotation und Thread-Umstellung laufen PARALLEL. Sie blockieren einander nicht — der Passphrase-Override je MAC (/interface wifi access-list, s. Follow-up) macht den Flag-Day überflüssig: neuer PSK aufs Profil, die noch nicht migrierten Geräte übergangsweise per MAC mit dem alten weiter. Einzige Regel, damit die Parallelität nichts kostet: ein Gerät, das ohnehin auf Thread/Zigbee wandert, bekommt den neuen PSK gar nicht — es kommt auf die Override-Liste und verschwindet später ganz. (Die frühere Formulierung „blockt die Rotation" war zu streng; die Reihenfolge war nie technisch nötig, nur ökonomisch.)
• Abh.: keine harten fürs Netz. Läuft parallel zur PSK-Rotation (User-Entscheid 08-23, vorher als Blocker geführt). Verwandt: TP12.1 (IPv6/Matter — profitiert direkt), TP25 (jedes Gerät weniger im 2,4-GHz-Band ist Funkruhe), TP17 im Archiv (Migrationshistorie + mcp/shelly/-Werkzeug).

TP17.3 — Shelly-Regression nach der VLAN30-Migration ▸ ✅ ERLEDIGT (2026-08-23, Folge-Session): beide Geräte repariert, Ursache eco_mode bewiesen — offen nur noch der Flotten-Entscheid (gehört TP17.1) — aus TP17 herausgelöst, User-Meldung

User-Meldung 2026-08-23: „vor einiger zeit hast du an den shellys änderungen vorgenommen. das hatte bei einigen einen bösen seiteneffekt: lüfter-shelly musste ich doppelt drücken. der übelste ist jedoch der von diele ug: seit deinen änderungen spinnt er herum und blinkt wie ein wilder. sobald AP on ist, ist die symptomatik weg. ich muss vermutlich eh alle shellys neu machen."

• 🔴 Erste Konsequenz, sofort: der aktivierte AP auf s23 ist ein WORKAROUND, kein Rest. Ich hatte ihn beim WLAN-Scan am selben Tag als „übrig gebliebenen Anker aus TP17, gehört abgeschaltet" eingeordnet — das war falsch, und es hätte Christophs Notbehelf zerstört. Er ist bewusst an. Nicht abschalten, bevor die Ursache behoben ist. (Merkregel: ein Zustand, der nach einem Verfahren „übrig" aussieht, kann eine Reparatur sein. Vor dem Aufräumen fragen, wozu er da ist.) ✅ Aufgelöst 2026-08-23: die Ursache ist behoben, der AP auf s23 ist abgeschaltet und wird nicht mehr gebraucht. Der Workaround hat exakt das getan, was die Hypothese vorhersagte.
• Symptome und Geräte:

  Gerät	Modell	Symptom
  s23 dieleug-wohnzimmer_licht .203	SPDM-002PE01EU, app ProDimmerx = Phasenanschnitt-Dimmer (Diele UG/Licht + Wohnzimmer/Seitenlicht)	„blinkt wie ein wilder", AP an ⇒ weg
  s26 bad_luefter .233	S4SW-002P16EU (Gen4), switch:0 in_mode=momentary	muss doppelt gedrückt werden

Was die Migration am Gerät wirklich verändert hat (TP17, 2026-07-13)

Vier Dinge, nicht nur die WLAN-Config: (1) STA-SSID/PSK · (2) statische IP statt DHCP (ipv4mode=static, gw/dns 10.40.30.1 — an allen 22 bestätigt) · (3) eco_mode nach einer RSSI-Politik · (4) AP-Anker an/aus.

🎯 ✅ BESTÄTIGTE URSACHE: eco_mode, nicht die WLAN-Config

• eco_mode senkt den CPU-Takt und die WLAN-Sendeleistung — so steht es in TP17 selbst.
• Ein Phasenanschnitt-Dimmer braucht präzises Nulldurchgangs-Timing. Ein gedrosselter Takt erzeugt Jitter in genau diesem Timing ⇒ Flackern. Das ist s23.
• Warum „AP an" heilt: ein aktiver Access Point muss beaconen, das Funkteil darf nicht in die Sparzustände. Der AP hebt also faktisch den Energiesparbetrieb auf — er behandelt das Symptom genau dort, wo die Hypothese die Ursache vermutet. Diese Korrelation ist das stärkste Indiz.
• s26: momentary-Eingang + gedrosselter Takt ⇒ die erste Flanke wird verschluckt ⇒ „doppelt drücken".
• ✅ Gegenprobe im Bestand: s12 dieleug_steckdosen hängt am selben Ort, ist dasselbe Gen4-Modell wie s26 — und hat eco_mode=false. Es ist unauffällig. (Kein Beweis, aber die Hypothese überlebt ihn.)
• ✅ Die Alternativerklärung ist damit erledigt: der Verdacht auf gerätespezifische Dimmer-Themen (Leading/Trailing Edge, Kalibrierung, Mindestlast/LED-Treiber) hat sich nicht bestätigt — eco_mode allein genügte. Nebenbei: die Config dieses Geräts kennt für Phasenan-/-abschnitt ohnehin keinen Parameter; Stellschrauben wären nur warmup, range_map, gamma, min_brightness_on_toggle gewesen. Der Link war mit −54 dBm die ganze Zeit sehr gut, ein reines Funkproblem war nie plausibel.

Der diskriminierende Test (klein, reversibel, ein Gerät) — ▶️ AUSGEFÜHRT 2026-08-23

1. ✅ s23: Sys.SetConfig {"config":{"device":{"eco_mode":false}}} — AP zunächst AN gelassen. cfg_rev 91 → 92, eco_mode=false gelesen.
2. ✅ Christoph beobachtet: „licht in diele ug ist jetzt flackerfrei". ⚠️ Das ist noch kein Nachweis — mit AP an war es vorher schon flackerfrei. Beide Hypothesen sagen an dieser Stelle dasselbe voraus. (Merkregel feedback_abnahme_wirkung_nicht_anzeige.)
3. ✅ AP aus (WiFi.SetConfig ap.enable=false) — damit war der Test scharf: eco_mode=false, ap.enable=false, STA got ip 10.40.30.203 bei −54 dBm.
4. 🎯 ERGEBNIS — Christoph, 2026-08-23: „beide lampenausgänge getestet. funktioniert perfekt, kein flackern." Genau die Konstellation, die vorher geflackert hat, ist ohne AP stabil. ⇒ eco_mode war die Ursache. Hypothese bestätigt, s23 repariert.
5. ✅ s26 bad_luefter analog: eco_mode=false gesetzt (cfg_rev 18 → 19) + Reboot (s.u.). 🎯 ERGEBNIS — Christoph: „lüfter perfekt." Der Doppeldruck ist weg. ⇒ Beide gemeldeten Geräte repariert, beide Symptome durch dieselbe Ursache erklärt.

🔴 Korrektur einer Annahme aus dieser Session: ich hatte gewarnt, eco_mode brauche einen Neustart, um zu wirken, und der Test sei deshalb unvollständig. Falsch — das Gerät antwortet auf Sys.SetConfig selbst mit {"restart_required": false}. Der Test war richtig formuliert, ein Reboot des Dimmers (= Lichtausfall in Diele UG/Wohnzimmer) wurde daraufhin nicht ausgeführt. (Und daraus folgt der wichtigere Schluss: eco_mode kann das restart_required der 14 Geräte unten nicht verursacht haben.)

Weitere Funde aus dem Sweep vom 2026-08-23 (read-only, alle 22 Geräte)

• 🔴 Die eco-Politik ist damit nicht nur stale, sondern WIDERLEGT. Regel von 2026-07-13 war „eco an bei RSSI ≥ −80, aus darunter" — sie hat an s23 realen Alltagsschaden erzeugt und war nie konsistent umgesetzt. Ist-Stand des Sweeps 2026-08-23 (22 Geräte, live): eco AUS: s7 (−90), s12 (−64), s17 (−76), s18 (−81), s19 (−88) · eco AN: alle übrigen 16, darunter s20 (−85) und s21 (−85) — die RSSI-Regel ist an keiner Kante mehr erkennbar. Die Werte haben sich seit Juli durch TP25/TP28 ohnehin verschoben. Die in TP17 vorgemerkte „2. Evaluation nach TP3.3" hat nie stattgefunden. ⇒ ✅ ENTSCHIEDEN UND AUSGEFÜHRT 2026-08-23. User: „eco-mode für alle deaktivieren. der rotz macht nur probleme." 13 Geräte umgestellt (s5, s6, s8, s10, s11, s13, s14, s15, s16, s20, s21, s22, s25), null Fehler; 9 standen bereits auf false. Stand jetzt: eco_mode=false auf allen 22 erreichbaren Shellys, einzige Ausnahme s24 (SNDC-0D4P10WW meldet eco_mode: None — nicht unterstützt). Offen nur s1/s2/s3 (weihnachten_*, saisonal stromlos). 🔧 Werkzeug: mcp/shelly/migrate.py eco <range> [--go|--on] — neu, über denselben _rpc-Pfad, mit Retry je Gerät (ein Timeout an einem schwachen Link darf den Sweep nicht abreißen) und einer Fehlerliste am Ende.

  🔬 Und die Gegenmessung widerlegt meine eigene Warnung. Ich hatte hier notiert, eco aus hebe die Sendeleistung an und sei deshalb eine Airtime-Änderung, die TP25 berühre. Gemessen stimmt das nicht: Signal der 13 geänderten Geräte in der Registration-Table des Managers, vorher/nachher — Mittel −0,9 dB, Median −1 dB, Spanne −3..+3, bei einer Kontrollgruppe von 13 unveränderten Geräten mit +0,0 dB und derselben Streuung. Das ist Rauschen, kein Effekt. ⇒ Die Aussage aus TP17, eco_mode senke „den CPU-Takt UND die WLAN-Sendeleistung", stimmt nur zur Hälfte. Der Takt-Teil ist durch das Dimmer-Flackern bewiesen; der Sendeleistungs-Teil ist an diesen Geräten nicht messbar. Kein Funkbild-Argument mehr für oder gegen eco.

• ✅ AP-Anker-Sweep erledigt (der offene read-only-Punkt aus der Übergabe): WiFi.GetConfig → ap.enable über alle 22 Geräte. Nur s23 hatte einen AP an (= Christophs Workaround, inzwischen abgeschaltet), die übrigen 21 stehen auf false. Kein Aufräumbedarf, kein weiterer Anker im Bestand.

• 🔵 Nebenbefund, gehört nicht hierher, aber nicht verlieren: alle Shellys stehen auf sys.sntp.server = time.cloudflare.com. Kanonisch ist seit 2026-08-18 der Core als Zeitquelle, ausgeliefert per DHCP-Option 42 — die Shellys haben aber aus TP17 statische IPs und sehen die Option nie. Funktioniert (Uhrzeit stimmt, udp/123 aus VLAN30 geht raus), ist aber ein blinder Fleck in der NTP-Vereinheitlichung. Gleiche Klasse für jedes statisch adressierte Gerät im Netz.

• 🔵 inventory/bf.csv ist bei s12 stale: dort steht noch 10.40.41.219, live ist das Gerät auf 10.40.30.219 (migriert). Die drei weihnachten_* (s1–s3) sind saisonal stromlos, s4 kueche_mikrowelle offline — das erklärt 26 Einträge vs. 22 erreichbare.

• 🟠 restart_required = true — nicht auf 2 Geräten, sondern auf 14 von 22 (Sweep 2026-08-23, Folge-Session): s5, s6, s7, s10, s12, s13, s16, s17, s18, s19, s20, s21, s24, s26. Uptimes 22–41 Tage. ✅ Entwarnung, empirisch: s26 wurde kontrolliert neu gestartet und die Config davor/danach verglichen — sie ist identisch. Der Flag stand für keine abweichende Konfiguration; er ist ein sticky Bit, das nur nie zurückgesetzt wurde. Die Geräte sitzen nicht auf versteckten Änderungen. Reboots können damit gefahrlos gebündelt mit TP17.1 laufen.

• 🔍 Was restart_required gesetzt hat, ist am Gerät NICHT rekonstruierbar — drei Wege zu Ende gegangen: (a) 169 RPC-Methoden auf s26, keine gibt Auskunft über Pending-Zustand; (b) der Config-Diff über die Gruppengrenze trägt nicht — die Gen3-Familie S3PL-00112EU hat identische Configs, davon s6/s7/s10 flagged und s8/s11/s14/s15 sauber; (c) kein persistentes Gerätelog (sys.debug.file_log.enable=false, /debug/log ist ein Live-Stream ohne Ring-Puffer). Ausgeschlossen sind immerhin matter.enable, ble.rpc.enable, cloud, mqtt, ws (trennen die Gruppen alle nicht) — und eco_mode (s.o.). Nicht erneut untersuchen; der Aufwand ist gedeckelt und das Ergebnis negativ.

Scope / Abgrenzung

• Gehört hierher: alles, was die Migration am Gerät verstellt hat (eco_mode, statische IP, AP-Anker) und was daraus an Fehlverhalten folgt.
• Gehört nicht hierher: die Funkumstellung selbst (TP17.1, verworfen) und das Geräte-Passwort (seit 2026-08-24 TP30 Posten #3, vormals TP17.2).
• 🔗 Aber die Verzahnung mit TP17.1 ist der Hebel: wenn ohnehin alle Shellys angefasst werden, ist das der Moment, eco_mode grundsätzlich zu entscheiden statt gerätweise zu pflegen. Christophs „ich muss vermutlich eh alle shellys neu machen" ist damit nicht Resignation, sondern der effiziente Weg — nur eben nach dem Test, nicht davor.
• Governance: Shellys laufen nicht über Nautobot GC (kein Netzgerät im GC-Sinn). Änderungen über mcp/shelly/ bzw. direkte RPC. ⚠️ migrate.py hat kein Kommando für eco_mode — der Sweep-Weg wäre eine kleine Ergänzung über denselben Pfad.
• Abh.: keine. Blockt nichts. Der Alltagsschaden ist seit 2026-08-23 behoben.

📌 Was noch offen ist (Stand 2026-08-23, Folge-Session)

1. ✅ Tastentest s26 — erledigt, Doppeldruck weg.
2. Flotten-Entscheid eco_mode aus für die übrigen ~20 Geräte — gebündelt mit TP17.1 wegen der Funkbild-/Airtime-Wirkung (s.o.). Gehört Christoph.
3. migrate.py um ein eco-Kommando ergänzen, wenn 2. beschlossen wird — heute gibt es dafür keinen Pfad im Werkzeug, der Sweep lief ad hoc.
4. Reboots der verbleibenden 13 restart_required-Geräte — gefahrlos (empirisch an s26 belegt), deshalb kein eigener Termin, sondern Mitnahme bei TP17.1.

TP18 — Souveräner Objektspeicher (Garage, Multi-Site, S3-Cold-Tier) ▸ 🔜 KONZEPT (2026-07-12)

• Auslöser: 9-TB-Syno-Backup-Volume zu 2/3 voll; reine Daten ~3 TB, Tendenz steigend, „schlagartiger" Bedarf nicht ausgeschlossen. „Wenn skalieren, dann jetzt Syno-Nachfolger mitdenken."
• Kriterien (User-priorisiert): (1) keine Fremd-Abhängigkeit / kein Cloud-Lock-in (Cloud-Opex abschreckend); (2) Multi-Site BF/FM/DW; (3) HA (Standort-Verlust überlebbar); (4) billig/teuer trennen — Variante „kalt = Objektspeicher, heiß = lokal" genügt (kein Hot/Cold innerhalb des Stores nötig); (5) horizontal + vertikal skalierbar; (6) S3-API als Branchenstandard, den jedes Backup-Tool spricht.
• Entscheid Engine = Garage (Deuxfleurs, Rust): einziger Kandidat, der geo-verteilt über offenes Internet/WAN latenztolerant ist (CRDT-Metadaten, eventually consistent) → passt aufs 3-Keller-Modell BF/FM/DW. Ceph verworfen (will Sub-ms-LAN, Single-Cluster-über-WAN = Anti-Pattern; zu schwer, ~1 GB RAM/TB). MinIO (AGPL + Console/Feature-Abbau 2025) und SeaweedFS (kann Hot/Cold + Erasure-Coding, aber komplexer, Multi-Site async) = Fallback, falls später feingranulares Tiering / EC-Effizienz bei zweistelligen TB dominant wird.
• Entscheid Disk-Layout = JBOD, KEIN RAID. Redundanz gehört in eine Schicht: Garage RF=3 über 3 Sites ist die Redundanz. RAID 1 darunter = Doppelt-Bezahlen (3 Sites × 2 Mirror = 6× roh für 1× nutzbar, absurd). RAID 0 verworfen (1 Platte tot = ganzer Node-Rebuild über WAN). JBOD = jede Platte eigenes Garage-Data-Dir (v1 Multi-HDD): Failure-Domain = 1 Platte, Rebuild nur deren Anteil, kein Kapazitätsverlust. Merksatz: distributed store = „just a bunch of disks", Redundanz ausschließlich über die Sites.
• Was man dafür bezahlt: Plattentod triggert Re-Replikation über WAN (durch Upload-BW gedeckelt). Bei ~3 TB/Site tolerabel; wenn Bedarf „schlagartig" auf zweistellige TB springt → mehr/kleinere Platten (Blast-Radius) oder 4. Node, ggf. Wechsel auf SeaweedFS-EC.
• Dimensionierung (Planungsanker 10 TB nutzbar; heute 3 TB unique / 6 TB Backup-used): RF=3 → 30 TB roh gesamt = 1 volle Kopie ~10 TB/Site (provisionieren ~16 TB roh/Site: 2 Platten = halber Blast-Radius + Headroom). Linear skalierend.
• Kostenmodell (Annahmen: HDD neu CMR ~€18/TB · recert ~€10/TB · Strom €0,25/kWh · Lean-Node Mini-PC/pve 12 W + 2 HDD ~20–28 W):
  • Capex kumulativ (3 Sites): Platten €540 (recert) – €900 (neu) + Nodes €400 (BF=pve €0; FM/DW je Mini-PC €200) = **€600–1.300**. Vergleich: ein resilienter Syno-Nachfolger für 10 TB = €1.000–1.600 capex ohne Geo-HA → Garage-3-Node gleich teuer/billiger mit HA.
  • Opex kumulativ: ~€135–185/J Strom — aber getrennt gerechnet: FM/DW laufen über fremde Zähler, auf Christophs Zähler landet nur der BF-Node ≈ €50–60/J (Gegenleistung: er hostet deren Kopie, reziprok wie TP16).
  • JBOD-vs-RAID1-Ersparnis: Strom bloß €9–22/J (Christophs Zähler) → kein Entscheidungsgrund; der Hebel ist Capex ~€900 (nicht gekaufte Spiegelplatten) + architektonische Korrektheit. (Reicht nicht für ein BW-Upgrade €120–240/J, taugt aber als Seed für HW-Rückstellungen.)
• Konzeptioneller Bruch (Syno-Nachfolger): Kein großes resilientes NAS mehr nötig — die kollektive 3-Site-Redundanz ist die Garantie. Syno-Rolle splittet: Hot/SMB/VM-Disks bleiben lokal (Syno oder ZFS auf pve, klein/schnell); Backup/Cold wandert in Garage über BF/FM/DW → das 9-TB-Volume wird aufgelöst statt ersetzt (aus 1 SPOF werden 3 geo-redundante Kopien). Backup-Tool (restic/Kopia) sprechen S3 nativ.
• Impacts auf Bestand (Kurz): (a) Storage-Redundanz-Philosophie kippt — weg von SHR/RAID pro NAS, hin zu 3× JBOD; (b) Backup-Kette Hyper-Backup/SMB → S3-Bucket umstellen; (c) Container-Host-System (TP14) kriegt Garage als LXC/Container je Site, aber auf rohen Platten, nicht auf bestehenden SHR-Volumes; (d) Upload-BW wird Durchsatz-/Rebuild-Limit; (e) HW-Planung verzahnt mit TP15 (Node-HW, pve-Standort) und TP24 (Stromversorgung je Site), FM/DW brauchen je 1 Node.
• Startpfad (inkrementell/reversibel): ① BF zuerst — Garage-Container auf pve, 2 HDDs JBOD, Backups lokal auf Bucket (sofort Nutzen, noch keine Redundanz). ② FM/DW nachziehen (Mini-PC + 2 Platten), RF→3, ab jetzt geo-redundant+HA. ③ Syno entlasten (Backup-Last abgeben).
• Offen (Modell scharfstellen): realer Strompreis; ob FM/DW eigene Nodes stellen oder Christoph HW hinstellt; Backup-Tool-Wahl (restic vs Kopia); ob heißes Zeug künftig auf ZFS/pve statt Syno.
• Abh.: TP10 (WG-Multi-Site = Transport, Upload-BW-Constraint), TP14 (Container-Hosts), TP15 (Node-HW) / TP24 (Stromversorgung), Muster von TP16 (reziprokes Per-Host-HA). Kein Blocker für laufende TPs. SSoT dieser Session.

TP20.1 — Vaultwarden → Platform-Postgres + Cross-Site-HA ▸ 🔜 KONZEPT (2026-07-14, ausgelagert aus TP20)

• Ziel: vw (.20.127, heute MariaDB) auf den Precious-Tier holen und das eigentliche User-Ziel erfüllen: DB-Replikation über 2 Sites (Standort-Verlust überlebbar).
• Phase 1 — Migration (single-site): vw MariaDB→Postgres (Export → Import in Tier-1-DB vaultwarden → DATABASE_URL umstellen → verifizieren). Danach ist vw precious + im pgBackRest/PITR-Schirm von TP20. (Alternative verworfen: vw auf MariaDB lassen + MariaDB-Repl — zugunsten EINER Replikations-/Backup-Mechanik im Precious-Tier.)
• Phase 2 — Cross-Site-Standby: db-platform-standby-LXC am 2. Standort → pg_basebackup/Streaming-Replication über WG (TP10) → manuelles Promote-Runbook. Repliziert den ganzen Tier-1-Cluster (vw = HA-Ziel, Nautobot bekommt Gratis-DR-Kopie). Patroni + 3. Witness nur, falls später Auto-Failover statt manuellem Promote gewünscht.
• Verwandt/Abgrenzung: vw ist auch in TP16 offen (CF-Access: bypass→WARP-geschützt) — DB-HA ≠ Access, getrennt behandeln. Reziprokes 2-Site-Muster analog TP16/TP18.
• Abh.: TP20 (Tier-1 Postgres muss stehen), TP10 (WG-Transport für Phase-2), TP18 (Backup-Schirm). Kein Blocker für TP21.

TP23 — DNS-Policy & Self-Service-Ausnahmen ▸ ⏳ STUFE 1 DURCH, STUFE 2 VORBEREITET (2026-08-18)

• ✅ Stufe 1 — DoH auf dem Core scharf (routeros/tp23-stufe1-doh-core.rsc), schliesst zugleich TP21.1 TODO 1. use-doh-server=https://px35ynlol3.cloudflare-gateway.com/dns-query, verify-doh-cert=yes. servers=1.1.1.1 bleibt als Bootstrap fuer den DoH-Hostnamen stehen.
  • 🔑 Die alte Begruendung „core hat kein CA-Bundle, verify also unmoeglich" war zu pessimistisch. Es braucht kein Bundle, sondern genau einen Root: die Kette ist Leaf → GTS WE1 → GTS Root R4, importiert wurde nur R4 (~1 KB, gueltig bis 2036) — bei 2,8 MB freiem Flash ist das der Unterschied zwischen geht und geht nicht. Fingerprint lokal und am Geraet gegengeprueft (349dfa40…3c7d).
  • 📌 Der Zertifikatsimport steht bewusst nicht im GC-Template: er braucht die Datei am Geraet und ist einmaliger Bootstrap, kein Sollzustand. Im Template steht nur die /ip dns set-Zeile.
  • ⚠️ Der Deploy meldete FAILURE, obwohl alles sass. /certificate import gibt failed: 0 aus, und der Job scannt den Geraete-Output stumpf nach dem Wort. Wieder ein Beleg fuer die TP22-Regel: Job-Status ist kein Wirksamkeitsnachweis, nur die Gegenpruefung am Geraet zaehlt.
• ⏳ Stufe 2 — AdGuard eingerichtet, aber bewusst NICHT scharf geschaltet (User-Vorgabe 2026-08-18). adguard_bf1 (10.40.20.16) macht bereits DoH zum selben CF-Gateway. Ergaenzt wurden: conditional upstreams [/bf.lan/]10.40.20.1 und [/40.10.in-addr.arpa/]10.40.20.1 (ohne die zweite Zeile wuerden interne Reverse-Lookups zu Cloudflare abfliessen), sechs CIDR-Client-Gruppen (ein VLAN = eine Gruppe) und die permanente Ausnahmegruppe dns-bypass-exempt (aktuell 10.40.10.183). Abnahme per dig: core.bf.lan → 10.40.99.1, nas.bf.lan → 10.40.20.10, extern ueber DoH. Backup AdGuardHome.yaml.bak-tp23-20260817.
  • Kein DHCP-Scope wurde angefasst — alle sieben liefern weiter 10.40.X.1 aus. Das Scharfschalten ist damit spaeter ein reiner DHCP-Change; die passende Firewall-Zeile (TP5-E2: LAN->AGH dns (Vorrat)) steht bereits, damit dabei die scharfe Firewall nicht angefasst werden muss.
  • ⚠️ AGH schreibt die YAML beim Start neu (eigene Schluesselreihenfolge, Kommentare weg, time_zone: Local → UTC). Wer die Datei patcht, muss danach am laufenden Stand pruefen, nicht am eigenen Entwurf.
• 🔜 Offen bleiben Stufe 3–6 (zweite AGH-Instanz, per-Lease Option 6, HA-Buttons, und zuletzt die Bypass-Sperre). Ausdruecklich keine HA/zweite Instanz (User 2026-08-18).
• Auslöser: sobald gefiltertes DNS scharf ist, gehen einzelne Seiten/Dienste kaputt. Es braucht Ausnahmen ohne Admin-Eingriff — per User/Client/Gruppe/global, temporär oder permanent, mit Oberfläche. Bedarf ist belegt, nicht vermutet: der bisherige Workaround war „Client von Hand auf 1.1.1.1 stellen", regelmäßig (User 2026-08-14).
• 🔴 Zentrale Reihenfolge-Regel: genau dieser Workaround IST der DNS-Bypass, den TP5 schließen will → erst der Ersatz, dann die Sperre. Ohne funktionierende Ausnahme-Oberfläche verliert u.a. der Entwicklungsrechner samt Agenten-Toolchain seinen Ausweg — und DNS-Blocks äußern sich dort nicht als klare Meldung, sondern als diffus kaputte Build-Umgebung.
• Zwei Befunde, die die Architektur bestimmen:
  1. DoH ist nicht das Problem. Clients sprechen plain mit dem lokalen Resolver, der macht DoH nach oben — die empfohlene Auflösung des DoH/Split-Horizon-Konflikts, bf.lan bleibt heil. Was Seiten blockiert, ist die Policy. ➡️ Nie einen „DoH aus"-Schalter bauen, sondern Policy-Ausnahmen.
  2. Identität existiert nur dort, wo die Client-IP sichtbar ist. Router-DoH aggregiert alle Clients hinter einer Quelle — CF sieht nur den Core. Per-User-Identität bei CF verlangt einen Agent (WARP; bei NextDNS/ControlD deren CLI) → auf Shelly/Sonos/TV unmöglich. RouterOS kann keine per-Client-Ausnahme (keine DNS-Views; /ip dns static wirkt domain-weit — verifiziert). ➡️ Ein lokaler Resolver mit Client-Policy ist unvermeidbar.
• ✅ Architektur-Entscheid: Filter zentral bei CF, Identität + Ausnahmen lokal. Die Filterliste bleibt vollständig bei Cloudflare (Core via DoH, unterwegs via WARP); lokal wird nie eine Filterliste vorgehalten, nur die Diffs. Vorteile: kein RAM-Thema auf dem Core (eine Adlist kostet ~1,9 KB/Domain, 50k ≈ 95 MB — Konkurrenz mit Conntrack/DHCP/WG), eine Policy-Quelle statt zweier, gleiche Regelbasis zuhause wie unterwegs.
• ✅ Resolver-Wahl: AdGuard Home (läuft bereits, 10.40.20.16). Vergleich gegen die realen Anforderungen:
  • Pi-hole disqualifiziert: spricht kein DoH → bräuchte cloudflared/unbound als Sidecar (vierte QUIC-Komponente neben den drei TP16-Connectoren). Dazu belegtes Bruchrisiko v5→v6 (FTL/API/Web neu, Docker-Env-Variablen tot).
  • AGHs „keine Gruppen"-Schwäche verschwindet hier, weil Clients als CIDR eintragbar sind → 10.40.30.0/24 = die IoT-Gruppe. Die VLAN-Segmentierung ist bereits die Policy-Grenze. Dazu natives DoH, per-Device-ID auch bei wechselnder IP, „Unblock for this client", API + HA-Integration.
  • Technitium = ernsthafte Alternative (autoritativer DNS + DHCP + Apps, networkGroupMap); seine IP/Subnet-Bindung trifft uns kaum, weil die IPs per Reservierung faktisch statisch sind. Neubewertung legitim (die TP4-Ablehnung galt einer anderen Frage) — sinnvoller Anlass wäre, DNS und DHCP zusammenzuführen. Eigener TP, nicht dieser.
  • Verworfen: eigene Self-Service-UI bauen · per-Device-DoH via NextDNS/ControlD (Agent-Zwang, bricht bf.lan) · Umbrella ($30–45/User/Jahr) · Cloudflare verlassen (wirft TP16/TP16.1 weg) · Adlist auf dem Core.
• Zuweisung ist nativ möglich: /ip/dhcp-server/lease hat die Property dhcp-option (verifiziert) → Option 6 pro Lease, bei 54 Reservierungen ein Konfigurationsschritt. (Nebenfund: Leases haben address-lists → automatische Aufnahme in eine Firewall-Liste, direkt nützlich für die TP5-JIT-Gruppe.)
• ✅ WARP im LAN abschalten — Mechanismus: Cloudflare „Managed Networks". Der Client sucht bei jedem Netzwechsel einen selbst gehosteten TLS-Endpunkt, prüft dessen SHA-256-Fingerprint und zieht ein Device-Profil, das WARP deaktiviert. Beacon auf NAS/pve, nicht auf den Core (certs=0). Beseitigt die ICMP-Falle vom 2026-08-13 (ref_warp_local_icmp_trap) an der Wurzel.
  • ✅ Kollision aufgelöst (2026-08-14): die frühere Sorge war, dass TP16-Schritt 5 vw auf WARP-geschützt hebt und damit „WARP zuhause aus" bricht. Der User-Constraint aus TP16.2 streicht genau das — vw bleibt bypass und verlangt nie Device-Identity. Damit steht der Managed-Networks-Weg frei. Rest-Risiko nur für Dienste, die künftig doch Device-Identity verlangen sollten → dann Access-Policy zusätzlich auf die Heim-IP (bf4-home-ip existiert bereits).
  • ✅ Kein Verlust beim Fremdnetz-Zugriff: FM/DW laufen über den WG-Hub (TP10), nicht über WARP. Managed Networks schaltet nur im Heimnetz ab.
  • ⚠️ Free-Plan-Verfügbarkeit des Features nicht belegt → im Dashboard gegenprüfen. Holzhammer-Alternative (WARP-Endpunkte per Firewall sperren) nicht empfohlen: bricht still, Client probiert Transport-Fallbacks, trifft auch Gäste.
• Umsetzung in Stufen — Sperre zuletzt:
  1. DoH auf dem Core scharf → schließt TP21.1-TODO 1 (heute plain 1.1.1.1); CA-Bundle nötig.
  2. WARP-Managed-Network (Beacon auf NAS/pve) → WARP zuhause aus.
  3. AGH in den Pfad, zweite Instanz + Config-Sync, beide per DHCP als DNS 1 + 2.
  4. Client-Gruppen per CIDR (ein VLAN = eine Gruppe); per-Lease Option 6 nur für Abweichler.
  5. HA-Buttons für temporäre Freigaben + JIT (AGH-API, RouterOS-REST, CF-API), RouterOS-scheduler als Backstop, damit Ablauf auch ohne HA greift.
  6. 🔴 Erst jetzt (in TP5): DNS-Bypass sperren — Vorbedingung: Freigabe über HA funktioniert nachweislich, und die permanente Ausnahmegruppe dns-bypass-exempt (Entwicklungsrechner + Build-/Agent-Tooling) steht. Dann: nur Resolver dürfen 53/853 nach außen (schließt Geräte, die eigene Resolver hardcoden — Smart-TV mit 8.8.8.8 ist der Klassiker).
• Grenzen, offen benannt: ein Resolver im Datenpfad ist unvermeidbar (zwei Instanzen federn ab, ⚠️ AGH hat kein natives HA → Config-Sync ist Betriebsaufwand, sonst gilt nach Failover eine andere Policy) · keine Blockseite bei HTTPS (gilt für jede DNS-Filterlösung, auch Umbrella) · CF-Log-Retention 24 h im Free-Plan — laut User ausreichend, weil Ausnahmen JIT entstehen und ältere Fälle reproduziert werden.
• ⚠️ 802.1X löst die IoT-Identität NICHT: Consumer-IoT (Shelly, Sonos) hat keinen 802.1X-Supplicant; der Standardweg ist MAB = wieder MAC-basiert → kein Identitätsgewinn gegenüber der DHCP-Reservierung. TP8 bleibt richtig, aber als Sicherheitsthema (dynamische VLAN-Zuweisung, kein MAC-Spoofing bei Managed-Geräten), nicht als DNS-Identitätsquelle.
• Abh.: TP21.1 TODO 1 (DoH auf core), TP5 (Firewall/Bypass-Sperre — Reihenfolge s.o.), TP16 Schritt 5 (Access-Kollision), TP16.1 (falls WARP zuhause bleiben soll), TP8 (nur Sicherheit). Kein Blocker für TP5 → TP6, aber TP5 darf die Bypass-Sperre nicht vorziehen.

TP24 — Unterbrechungsfreie Stromversorgung (DC-USV, 48V-Bus) ▸ 🔜 KONZEPT — aus TP15 herausgelöst (User-Entscheid 2026-08-16) — docs/hw-refresh-requirements.md §9

• Warum ein eigener TP: Die USV hing bisher als Unterpunkt in TP15 (HW-Refresh Switching/Router) mit. TP15s Kernauftrag — CRS326-Beschaffung, Bring-up, Core-Tausch — ist seit 2026-08-08 durch; die Stromversorgung ist als einziger Rest übrig geblieben und hat mit Switching sachlich nichts zu tun. Sie ist ein eigenständiges Infrastruktur-Thema mit eigener Einkaufs-, Verkabelungs- und Entscheidungslogik (Elektrik, Batterie, Standort) und blockiert nichts auf dem kritischen Pfad. Darum eigener TP.

• Was es ist (Begriffsklärung): eine Pufferbatterie für die Netz-/Infrastruktur-Hardware — keine klassische AC-USV mit 230-V-Steckdosen. Ein 48-V-Gleichspannungsbus versorgt die Geräte direkt an ihrem DC-Eingang; die Batterie hängt am selben Bus und übernimmt bei Netzausfall ohne Umschaltlücke. Der Umweg AC→DC→AC→DC (und damit dessen Dauerverlust) entfällt.

• Zielbild (Aufbau, unverändert gültig aus der TP15-Recherche):

  Teil	Typ	Preis	Wirkungsgrad
  Netzteil	MeanWell LRS-150-48 (150 W, 48 V)	~€30	~88 %
  DC-USV-Modul	MeanWell DDR-120-48 (120 W)	~€80	~95 % (pass-through)
  Batterie	LiFePO4 12,8 V / 20 Ah (256 Wh)	~€50	—
  DC-DC 12 V	MeanWell SD-100A-12 (100 W, für NAS/pve)	~€30	~85 %
  Summe		~€190

  230 V AC → LRS-150-48 → 48-V-Bus → Switches direkt · → DC-DC 12 V → DS923/pve · → DDR-120-48 → LiFePO4.

• Warum 48 V: PoE-Technik arbeitet nativ mit 44–57 V (kein Wandler nötig), höhere Spannung = kleinere Ströme = weniger Leitungsverlust, und 48 V ist der Telecom-/USV-Standard.

• Laufzeit (256 Wh): ~2,5 h bei 100 W reiner DC-Last · ~5,5 h wenn nur Switch + PoE (45 W) · ~2 h wenn ein Inverter für den Mac mini mithängt.

• Effizienz-Argument (der eigentliche Grund für DC statt AC): eine AC-USV verheizt bei 100 W Dauerlast ~25–40 W (≈ €66–105/Jahr), die DC-Variante 5–12 W (≈ €13–32/Jahr) — bei praktisch gleicher Anschaffung (€190 vs. €150–250). Der Mehrpreis amortisiert sich über den Dauerbetrieb.

• ✅ DC-Eingang vorhanden (geprüft): crs326-core + crs326-branch (12–57 V, DC-Jack) · ap1/ap2 hAP ax² (12–57 V, alternativ PoE-in). ⚠️ Adapter/Sonderfall: DS923+ (externes 12 V/7 A, 4-Pin Mini-Fit JR) · pve/N100 (12 V Hohlstecker) · Mac mini hat gar keinen DC-Eingang (eingebautes Netzteil → nur über Inverter).

• Offene Entscheidungen (aus TP15 mitgenommen, unverändert offen):

  1. Mac mini auf USV? Braucht einen Inverter (~15–20 % Verlust + Komplexität). Vorfrage: läuft er überhaupt 24/7? Wenn nein, reicht ein Graceful-Shutdown-Script auf USV-Warnung.
  2. Standort/Verkabelung: Der Bus soll laut Skizze im Arbeitszimmer/Technik OG sitzen — der L3-Core steht aber in Technik UG. Entweder zweiter Zweig nach unten oder Bus dorthin, wo der Core steht. Diese Frage ist durch den Core-Umzug neu zu stellen (die Skizze stammt aus der Zeit, als oben der Verteiler geplant war).
  3. Arris-Kabelmodem: vorentschieden auf Grid (muss ohnehin am Netz bleiben, DC-Zweig nach unten wäre Aufwand für ~1–2 W).
  4. Batteriegröße: 20 Ah als Startwert; 50 Ah wenn die gepufferte Last über Switch+AP hinaus wächst.
  5. Monitoring/Shutdown: wie meldet die USV einen Netzausfall an NAS/pve (Signalkontakt vs. nichts)? Ohne das gibt es kein sauberes Herunterfahren, nur Durchhalten bis die Batterie leer ist.

• Nutzen konkret: bei Stromausfall bleiben Core-Switch, Branch-Switch und beide APs online → Netz, WLAN und der WG-Hub überleben (der WAN-Uplink nur, solange auch der Arris Strom hat, s. Entscheidung 3). Für NAS/pve zählt vor allem das kontrollierte Herunterfahren statt des harten Abschaltens.

• Abh.: keine harten. TP15 ✅ (die zu versorgende Hardware steht und hat DC-Eingänge). Verwandt: TP18 (Garage-Nodes brauchen je Site eine Stromversorgung), TP11 (USV-Zustand ins Monitoring). Kein Blocker für TP5/TP6.

• Historie: war bis 2026-08-16 Unterpunkt von TP15 („🔋 DC-USV: MeanWell LRS-150-48 + DDR-120-48 + LiFePO4 20Ah (~€190), 48V-Bus; CRS326 DC-input passt"). Vollständige Recherche inkl. Schaltbild, Effizienzvergleich und Gerätetabelle: docs/hw-refresh-requirements.md §9 (+ §10 D/E/F für die offenen Fragen).

TP25 — WLAN-Stabilisierung ▸ 🟢 KERN ERLEDIGT (2026-08-22): Dead Spot Terrasse repariert (43 % → 9 % Verlust, 20,4 s → 1,0 s). Fund F ✅ aufgelöst (08-24, geräteseitig — kein Netzfehler), 5-GHz-Umfeldscan ✅ (08-24), Kanalplan für AP 3 ✅ gerechnet. Offen nur noch die Umsetzung, wenn der dritte AP kommt. Nicht mehr kritischer Pfad — Sammel-TP für Christophs Beobachtungen 1–6

📚 Kondensiert am 2026-08-23 (Doku-Session, Punkt F). Dieser Abschnitt war mit 394 Zeilen 18 % der Datei. Die Langfassung steht vollständig und unverändert im Archiv: teilprojekte-archiv.md → TP25 (Langfassung) — Messchronik (A)–(G), Funde A–E im Volltext, die beantworteten Fragen (Beobachtung 5, ch149-Herkunft, 2ghz-g, Deckenmontage), Umsetzungsreihenfolge mit allen Deploy-Gotchas. Hier steht: Stand, Offenes, Merkregeln. Wer an TP25 weiterarbeitet, kommt mit diesem Abschnitt aus; wer wissen will warum etwas so entschieden wurde, liest die Langfassung.

Stand 2026-08-22, 23:30 — die Terrasse ist repariert. Erster Lauf mit beiden Ping-Strecken (tp25-runde-20260822-2330-auswertung.md): 43 % Verlust / 20,4 s längste Lücke (08-21) → 9 % / 1,0 s bei gleichem Gerät und gleicher Rolle. Wirksam war das Anheben von ap2 auf 2,5 m; 1,0 s liegt unter der Hörbarkeitsschwelle im Call. Der Dead Spot, der TP25 seit dem 08-20 getragen hat, ist damit weg.

🔎 Kernbefund, der bleibt: das Netz ist gut, die Redundanz ist es nicht. Die frei roamende Referenz hat in 17 von 21 Raumabschnitten 0 % Verlust; der Gegen-AP liefert Schlafzimmer −84,6/38 %, Bad −82,3/24 %, Küche −82,0/23 %, Terrasse −78,7/19 %. Fällt ein AP aus, ist die halbe Wohnung „verbunden, aber tot". ⇒ Ein dritter AP ist nach Christophs eigener Randbedingung derzeit NICHT begründet — er kaufte Redundanz, keine Abdeckung. Das ist eine andere Frage und Christophs.

Beide vormals offenen Punkte sind am 2026-08-24 abgearbeitet — Fund F ist aufgelöst, der 5-GHz-Umfeldscan gefahren und der Kanalplan für einen dritten AP gerechnet. Was von TP25 bleibt, ist Umsetzung bei Bedarf, keine offene Frage:

1. ✅ Fund F — GEMESSEN UND AUFGELÖST (2026-08-24): kein netzseitiges Phänomen. Kollektor am Manager (/interface wifi registration-table, 15-s-Takt, 29 Samples über 7,7 min, 28 Clients), Rohdaten docs/messdaten/tp25-fundf-20260824.log. Von den drei Kandidaten sind zwei erledigt, einer bleibt — und die zwei fielen ohne Wartezeit:

   Kandidat	Ergebnis	woran es hängt
   (b) DHCP-lease-time gegen die Periode	❌ tot	dhcp-v30 fährt lease-time=1d → Renew bei 12 h. Kann 5:05 nicht erzeugen. Eine Abfrage, keine Messung.
   (a) periodischer VAP-Re-Apply	❌ tot	Ein Re-Apply wirft alle Clients des VAP gleichzeitig. Auf cap-wifi4-virtual1 standen zeitgleich drei Clients bei 16 h 51 min Uptime, 25 von 28 über 6 h. Mit einem 5-Minuten-Takt ist das unvereinbar.
   (c) das Gerät selbst	🟡 bleibt	Der einzige Client, der im Fenster überhaupt neu verband.

   🔑 Der entscheidende Punkt an der Beweisführung: dafür braucht es die vier Zyklen nicht. Ein einziges Sample mit 16 h 51 min Uptime auf genau dem VAP, der angeblich alle 5:05 abwirft, widerlegt (a) vollständig. Die Fensterlänge begrenzt nur, was man über abwesende Geräte sagen kann.

   🔴 Und genau die sind abwesend: die beiden Fund-F-MACs gibt es gerade nicht. 38:A5:C9:C0:73:1E (10.40.30.178) und 38:A5:C9:BC:33:31 (10.40.30.179) stehen in /ip arp auf status=failed, haben keine DHCP-Lease, stehen nicht in der Registration-Table und sind auch HA unbekannt (kein device_tracker zu diesen MACs). ⇒ Das Phänomen ist an diesen Geräten derzeit nicht reproduzierbar, weil die Geräte weg sind. 📌 Merkregel — dieselbe wie beim P750W: bevor ein periodisches Trennen als Funk- oder Konfigurationsfehler untersucht wird, erst prüfen, ob die betroffenen Geräte überhaupt da sind. Beim Drucker war die Fehldiagnose „Power-Save", hier wäre sie „VAP-Re-Apply" geworden.

   ⇒ Fund F wird geschlossen: was auch immer der 5:05-Takt war, er lag geräteseitig, und die zwei betroffenen Geräte sind vom Netz. Netzseitig ist nichts zu tun. Nicht erneut aufgreifen, solange .30.178/.179 nicht wieder da sind und das Muster erneut gemessen wird.

   🟡 Nebenbefund mit Substanz — der DTU ist der einzige Wackelkandidat, den es wirklich gibt. 54:F2:9F:12:51:F0 (DTU/Wechselrichter, auf cap-wifi4-virtual1 = ap1) war der einzige Client mit einem Uptime-Rücksetzer: 43 min Sitzung, dann weg für ein Sample, dann wieder da — bei −52 dBm, also bei tadellosem Signal. Das ist derselbe Mechanismus, der schon die Transaktion TP17.1-dtu-pin-ap2 begründet hat: ein ESP hat EIN Radio, sein eigener AP und die STA-Verbindung teilen sich den Kanal. Periode hier 43 min, nicht 5:05 — es ist nicht Fund F, aber es ist echt. ⇒ Gehört zur ohnehin vorgesehenen Neubewertung des DTU-Pins, sobald der Kanalplan steht (s.o.).

   📜 Ursprüngliche Fund-F-Formulierung (2026-08-22)

   1. 🟡 Fund F — IoT-Clients trennen exakt alle ~5:05 bei gutem Signal (−59 dBm, vier Messpaare, auf 3 s reproduzierbar → ein Timer, kein Funk). Muss am Manager nachgemessen werden, die AP-Tabellen sind unter CAPsMAN leer. Kandidaten und der Test, der sie trennt: (a) periodischer VAP-Re-Apply (Fund D war die Ursache → prüfen, ob es nach dem Fix weg ist); (b) DHCP-lease-time der beiden MACs (38:A5:C9:C0:73:1E, 38:A5:C9:BC:33:31) gegen die Periode legen; (c) das Gerät selbst mit 5-min-Duty-Cycle → dann bleibt es unverändert. 🚫 Nicht die alte Power-Save-Merkregel wiederbeleben — die ist am 2026-08-13 als Fehldiagnose zurückgezogen (ref_wifi_powersave_multicast).

2. ⚖️ Entscheidung 5 GHz auf 20 MHz (statt heute 20/40) — ✅ 5-GHz-Umfeldscan durchgeführt 2026-08-24, Empfehlung: NICHT verschmälern, Entscheidung an einen Auslöser hängen. ⚠️ 2,4 GHz NICHT vorschnell drosseln — dort hängen ~20 IoT-Geräte.

   Messung (/interface wifi scan am Manager, cap-wifi3 = ap1 / cap-wifi1 = ap2, 10–12 s):

   vom Radio auf	fremdes 5-GHz-Netz	Kanal	Signal	Abstand zum eigenen AP
   ap1 (5180/Ce)	Drei_H288A_5G_acHG	5745/ac/80 MHz	−86 dBm	19 dB darunter
   ap2 (5220/Ce)	LiwestBB93-5G	5200/ac/80 MHz (Block 5180–5240)	−89 dBm	24 dB darunter

   ⇒ Das 5-GHz-Band ist an beiden Standorten praktisch leer. Genau ein Fremdnetz je AP, beide rund 20 dB unter dem eigenen Pegel. Der Nachbar LiwestBB93-5G liegt mit 80 MHz zwar formal über beiden unserer Blöcke — bei −89 dBm ist das ohne Wirkung.

   🎯 Warum das gegen 20 MHz spricht — die zwei üblichen Gründe treffen hier nicht zu:

   • Fremdinterferenz: existiert nicht (−86/−89). Ein schmalerer Kanal hätte nichts abzuwehren.
   • Selbstüberlappung: existiert nicht. ap1 5180/Ce = ch36+40, ap2 5220/Ce = ch44+48 — überlappungsfrei (Fund C, 08-17).
   • Bleibt allein das +3 dB Link-Budget — und das ist zum guten Teil schon vorhanden: in einem 40-MHz-BSS sendet die Ratenanpassung an schwache Clients ohnehin auf dem Primärkanal in 20 MHz. Den Ceiling zahlen aber alle Clients dauerhaft. Der Nutzen geht an die, die ihn schon haben.
   • Und es löst das gemessene Problem nicht: die offenen Schwachstellen sind die Redundanz-Lücken (Schlafzimmer −84,6 / 38 %, Bad −82,3 / 24 %) am Gegen-AP. +3 dB macht aus 38 % Verlust keine 0 % — das ist eine Platzierungs-/AP-Zahl-Frage, keine Kanalbreiten-Frage.

   🔑 Der echte Auslöser ist die AP-Zahl, nicht die Interferenz — und das ist der Grund, die Entscheidung jetzt zu treffen statt sie offenzulassen. Beide Kanäle stehen hart in Band A (ch-5g-ap1=5180, ch-5g-ap2=5220, kein skip-dfs-channels), und Band A hat unter ETSI genau 4 × 20 MHz = 2 × 40 MHz. Mit zwei APs ist es damit exakt aufgebraucht:

   Szenario	bei 40 MHz	bei 20 MHz
   2 APs (heute)	✅ passt genau, überlappungsfrei	✅ passt, +3 dB, halber Ceiling
   3.–4. AP	❌ Band A voll ⇒ nur mit DFS (Band B ch52–64: Radar-Events, 60 s CAC)	✅ 4 saubere Kanäle, kein DFS

   ⇒ Empfehlung: 20/40 MHz beibehalten. Die Verschmälerung ist heute ein Preis ohne Gegenwert. Sie wird fällig, sobald ein dritter AP dazukommt — dann lautet die Wahl nicht mehr „20 gegen 40", sondern „20 MHz flottenweit" gegen „DFS akzeptieren", und dafür ist 20 MHz die ruhigere Antwort. Ein Zwischenweg existiert (ap1 behält 40 MHz, AP 2+3 fahren 20 MHz auf 5220/5240) und braucht ebenfalls kein DFS. 📌 Damit ist dieser Punkt entscheidungsreif und an einen Auslöser gebunden statt offen.

📐 Kanalplan für den dritten AP ▸ gerechnet 2026-08-24, DFS vom User genehmigt

User-Vorgaben (2026-08-24): 20/40 MHz bleibt · DFS ist genehmigt, soll aber auf ap1 oder ap2 liegen, nicht auf dem Neuen · der Neue ist ein MikroTik-Deckenstrahler mit ax · möglicherweise kommt er an die Stelle eines der bisherigen APs · der vorhandene Outdoor-AP bleibt konzeptionell außen vor.

Das Kanalbudget unter ETSI (Indoor), als Rechnung statt als Gefühl. Ein 40-MHz-Block darf keine Bandgrenze überschreiten — [48+52] ist deshalb unmöglich, und daran hängt die ganze Knappheit:

Band	Frequenzen	Kanäle	40-MHz-Blöcke	DFS	EIRP
A	5150–5250	36/40/44/48	2 (5180/Ce, 5220/Ce)	nein	23 dBm
B	5250–5350	52/56/60/64	2 (5260/Ce, 5300/Ce)	ja + TPC	23 dBm
C	5470–5725	100–140	5	ja + TPC	30 dBm, outdoor erlaubt

Heute belegen zwei APs mit 40 MHz ganz Band A. Genau das macht den dritten AP zur Bandfrage — und mit genehmigtem DFS ist sie lösbar, ohne irgendwo auf 20 MHz zu gehen.

Empfohlene Zuordnung (3 APs, alle 40 MHz):

AP	Rolle	Kanal 5 GHz	Band	DFS	2,4 GHz
cAP ax (neu)	Primär, beste Position	5180/Ce (36+40)	A	nein	2437 (ch6)
ap1 hAP ax²	Sekundär	5260/Ce (52+56)	B	ja	2412 (ch1)
ap2 hAP ax²	Sekundär	5300/Ce (60+64)	B	ja	2462 (ch11)
—	Ausweichspur, frei halten	5220/Ce (44+48)	A	—	—

• Warum Band B und nicht Band C für die zwei DFS-Radios: gleicher 23-dBm-Deckel wie Band A (kein Leistungssprung zwischen den APs) und CAC 60 s statt 600 s — die 10-Minuten-Prüfung gilt im Wetterradar-Bereich von Band C. Band C bleibt damit frei für den Outdoor-AP, wo seine 30 dBm auch hingehören.
• Warum der Neue das nicht-DFS-Band bekommt: DFS kostet 60 s CAC bei jedem Boot und jeder Provisionierung plus einen erzwungenen Kanalwechsel bei Radar-Erkennung. Diese Kosten gehören auf die Radios, deren Fläche von einem anderen AP mitgetragen wird — nicht auf den bestplatzierten. Christophs Instinkt ist hier richtig.
• 2,4 GHz fällt nebenbei sauber: ch1/6/11 ist mit drei APs erstmals vollständig überlappungsfrei möglich (heute 1/11 mit einer Lücke in der Mitte).

🔴 Zwei Fallen, ohne die der Plan teurer wird als er aussieht:

1. Eine hart gepinnte Frequenz macht DFS zum Single Point of Failure. ch-5g-ap1/-ap2 tragen heute je genau einen Wert (frequency=5180 bzw. 5220). Bei einer Radar-Erkennung muss das Radio den Kanal verlassen — hat es keinen zweiten konfiguriert, bleibt das 5-GHz-Funk dieses APs unten. ⇒ Für DFS gehört in das Channel-Objekt eine Liste (z.B. frequency=5260,5280,5220), damit der AP neu wählen kann. Das ist der Unterschied zwischen „DFS ist unkritisch" und „DFS kostet einen AP".
2. Vor dem Umzug die erreichte Sendeleistung messen — das ist Fund B, nochmal. Band B/C verlangen TPC; ohne TPC sinkt der erlaubte EIRP um 3 dB. TP25 Fund B war exakt dieses Muster: 18 dBm gesetzt, 9 dBm gesendet, weil ch149 unter ETSI leistungsbegrenzt ist. ⇒ Diskriminierender Test, bevor irgendwas gekauft oder umgezogen wird: ap2 testweise auf 5260, dann /interface wifi monitor lesen und die tatsächliche tx-power gegen die heutigen 18 dBm auf 5220 stellen. Kostet eine Config-Transaktion und zehn Minuten, und entscheidet, ob der Plan trägt.

⚖️ Zur Platzierung — die Messung widerspricht dem Aufstellen an einer bisherigen Stelle. Die Referenzmessung vom 08-22 sagt: 17 von 21 Raumabschnitten haben 0 % Verlust. Zusätzliche Abdeckung ist damit wertlos. Der ganze Wert liegt im Gegen-AP: Schlafzimmer −84,6 / 38 %, Bad −82,3 / 24 %, Küche −82,0 / 23 %.

Variante	was sie bringt
Neuer AP an bisheriger Stelle	besseres Deckenbild an einem Punkt, der schon funktioniert. Die Drei-Zimmer-Lücke bleibt unverändert — gleicher Standort, gleicher Schatten.
Neuer AP an neuer Stelle (Richtung Schlafzimmer/Bad/Küche)	schließt die Lücke, also genau die Redundanz, die gekauft werden soll.
🎯 Beides: cAP ax an die bisherige Stelle, der verdrängte hAP ax² wandert in den Schatten	bestes Deckenbild dort, wo die Clients sind, und eine zweite Option in den drei Räumen. Braucht keine vierte Antenne, nur eine Steckdose/PoE im Zielraum.

⇒ Empfehlung: Variante 3. Sie ist der einzige Weg, bei dem der Deckenstrahler an den guten Platz darf, ohne dass die gemessene Schwäche unangetastet bleibt.

• Voraussetzung Neuer AP: PoE-in am Zielort (die cAP-ax-Reihe hat einen Gigabit-PoE-Port, kein Netzteil im Lieferumfang üblich) und ein Trunk mit VLAN 10/30/40/50/90/99 wie bei ap1/ap2. Der AP läuft auf wifi-qcom und tritt damit als regulärer CAP dem Manager bei — kein neues Modell im GC, nur ein weiteres Gerät plus zwei channel-Objekte. ⚠️ Exaktes Modell vor dem Kauf prüfen (cAP ax vs. cAP XL ax) — beide sind ax/wifi-qcom, unterscheiden sich in Abdeckung und Preis.
• Wenn später doch der Outdoor-AP dazukommt: er gehört nach Band C (30 dBm, outdoor zulässig); Band A/B sind dann von den drei Indoor-APs belegt und die Ausweichspur 5220/Ce ist aufgebraucht.

Fund E (signal-range-Boden am Manager) — abgestuft, NICHT umsetzen. Der Sticky-Client vom 08-20 reproduzierte sich am 08-22 nicht (Treppe: sauberer Wechsel ap2→ap1, 0 % über 57 s). Und auf der Terrasse würde ein Boden schaden, weil es dort keinen besseren AP gibt, auf den gesteuert werden könnte. ⇒ Erst wieder aufgreifen, wenn ein Sticky-Fall erneut gemessen ist. (Der Defekt ist nicht gegenstandslos, nur unbelegt: Fund B/C wurden am 08-20 mit ap1 auf ether15 gemessen — also in genau der Stellung, in der ap1 heute wieder hängt. Er ist platzierungsunabhängig.)

✅ Erledigte Funde — Ergebnis und Merkregel (Volltext im Archiv):

Fund	Ergebnis	Merkregel, die bleibt
A 2,4 GHz fuhr 40 MHz statt der profilierten 20	✅ 08-17: Inline-channel.* auf wifi1/wifi2 geleert → 2412/2462 @ 20 MHz	Inline-Overrides gewinnen gegen das verlinkte Profil — die SoT war die ganze Zeit richtig, das Gerät hat sie nicht befolgt
B ap2 sendete 5 GHz mit 9 statt 18 dBm	✅ 08-17: 5220/ax/Ce/I, 18 dBm	Der Fix ist gemessen, der Mechanismus nicht — beide ersten Erklärungen (ETSI-Band C, „80 MHz kostet generell") sind widerlegt. Resthypothese + diskriminierender Test (ap2 auf 5180/Ceee) stehen im Archiv und gehören vor einen Hardwarekauf
C 80 MHz kostete Randabdeckung	✅ 08-17: ch-5g auf 20/40mhz; ap1 5180/Ce, ap2 5220/Ce, überlappungsfrei	Unter ETSI gibt es im Indoor-Band nur einen 80-MHz-Block — zwei APs können dort nicht beide 80 MHz fahren. Genau deshalb war ap2 je auf 5745 gelandet
D w2-iot trug einen Channel-Override auf einem Slave-VAP	✅ 08-17: Overrides auf beiden APs entfernt, w2-iot seither BR	band ist eine Eigenschaft des Radios, nicht eines Slave-VAPs. War der Mechanismus hinter „alle SSIDs da, -iot beharrlich nicht"
Drift-Lücke — genau diese Overrides lagen außerhalb jeder ComplianceRule	✅ 08-18 mit dem TP28-GC-Umbau: wifi-*-Features hängen am Core, drei neue Rules; ein CAP hat keine Inline-Overrides mehr	„Compliant" heißt nur: die abgedeckten Sektionen sind sauber. Fund A und D blieben seit 08-08 unentdeckt, während die Flotte durchgehend compliant meldete

🔴 Deploy-Gotchas aus derselben Arbeit (kosten sonst zwei Deploys, Volltext im Archiv): /interface/wifi/set <if> !channel löscht die Inline-Sub-Properties NICHT — es wirft nicht, es tut nichts; richtig ist einzeln !channel.width !channel.band !channel.skip-dfs-channels. Und bei Kanalarbeit Breite VOR Frequenz ändern, sonst erzeugt man auf dem Weg eine Co-Channel-Kollision. ⚠️ steering=/Channel-Änderungen re-applien alle VAPs und werfen jeden Client kurz raus — nicht während eines Calls deployen, /system backup je AP vorher.

🔬 Messwerkzeug — vier Regeln, jede aus einem Fehlbefund geboren:

• 🔴 Für einen Kanal-/Umfeldscan NICHT list_wifi_interfaces benutzen (Fund 2026-08-24): das Tool gibt security.passphrase aller Profile im Klartext aus — ein Read für die Kanalbreite hat so fünf WLAN-Passphrasen in ein Transkript geschrieben, den IoT-PSK inklusive. Für Kanäle reicht /interface wifi channel print detail; für die cap-wifiN-Zuordnung … print where master=yes mit Feldauswahl. Der Scan selbst (/interface wifi scan) ist unbedenklich.
• 🔴 Die cap-wifiN-Nummern sind NICHT stabil. Der Manager vergibt sie in der Reihenfolge, in der sich die CAPs anmelden — nach dem ap1-Rückbau sind cap-wifi1/2 = ap2 und cap-wifi3/4 = ap1, umgekehrt zur früher fest verdrahteten Tabelle. ⇒ Die Zuordnung gehört zum Messlauf, nicht zur Auswertungszeit: tp25-walk-messung.sh friert sie als ap-map.txt ein, die Auswertung lässt die Namen sonst roh — unbeschriftet ist ehrlicher als falsch beschriftet. Läufe vor dem 2026-08-22 sind nicht rekonstruierbar; wer ihre AP-Namen zitiert, prüft sie an der Physik (der AP im Raum liefert dort das stärkste Signal).
• 🔴 Ein vom Pin abgewiesener Verbindungsversuch ist in Ping-Daten nicht von einem Funkloch zu unterscheiden — und der Manager protokolliert ihn auf info-Ebene gar nicht. Android quittiert die Abweisung mit „Verbindung fehlgeschlagen" und wählt das Netz ab; danach misst der Rest des Rundgangs Stille. Die Klick-Konsole schlägt deshalb Alarm, sobald das gepinnte Gerät nirgends hängt, und schreibt nach 45 s UNERREICHBAR=apX — denn „der Gegen-AP trägt hier nicht" ist das Messergebnis.
• 📐 Eine Runde, zwei Messpunkte (Christophs Aufbau 2026-08-22): das frei roamende iPhone zeigt, was ein normaler Client wählt — interessant ist der andere. Das S22 wird per access-list auf den Gegen-AP gezwungen (tp25-pin-s22.sh). Gute Referenz + schlechte Sonde = die Abdeckung steht, die Rückfallebene nicht. Memory ref_gegen_ap_messung.
• ▶️ Start ohne Werkzeugkette: bash docs/tp25-runde.sh [name] — legt den Lauf unter docs/messdaten/tp25-runde-<name>/ an, friert die AP-Karte ein, startet Konsole (Port 3031) und Messung, sagt die vom Interface gelesene Adresse fürs Telefon an und löst beim Beenden den Pin. Auswertung: tp25-gehweg-auswertung.py --dir ….
• ℹ️ Und das alles passiert TROTZ aktivem 802.11k/v und FT (st-main mit rrm=yes/wnm=yes, ft-over-ds=yes, live geprüft). Die Merkregel ref_ft_is_not_roaming („11k/v fehlen") ist historisch. Bei −48…−55 dBm kostet eine Übergabe 0–2,6 s, meist unter einer halben Sekunde — nicht die Übergabe ist teuer, sondern die schwache Zone.

User-Randbedingung (2026-08-17, wörtlich): „ich weigere mich einen anderen access point zu kaufen solange ich nicht das gefühl habe, wir haben alles aus dem ap rausgeholt." Das ist die Abnahmebedingung dieses TPs — keine Hardware-Empfehlung, bevor die Parameter stimmen. Der Boden ist gelegt (beide APs 18 dBm, überlappungsfrei, 20 MHz auf 2,4 GHz, ap2 auf 2,5 m); was übrig bleibt, ist die Redundanzfrage oben.

• Warum eigener TP: Christoph hat am 2026-08-16/17 sechs konkrete Beobachtungen gemeldet und ausdrücklich einen TP dafür verlangt; sie hängen alle an derselben Ursache-Klasse (Funkparameter, die nicht nach Manual gesetzt sind). TP25 übernimmt den offenen Rest von TP3.3 (Re-Walk, Dead-Spot-Kartierung — mit der Raumkarte vom 08-22 faktisch geleistet). TP3.2/TP3.3 stehen als Historie.
• Stand bei Sitzungsende 2026-08-22: Pin gelöst, Automatik aus, crs326-core unverändert und transaktionsfrei — die access-list steht unter keiner ComplianceRule, es gab nichts zu committen. (Seit 2026-08-23 gibt es die Rule wifi-access-list, s. TP22-Nachtrag — Fund E wäre ab jetzt transaktionsfähig.)
• 📋 Übergabe: handoff-tp25-session-20260821.md · Messungen: tp25-wlan-roaming-messung-20260820.md, tp25-runde-20260822-2330-auswertung.md
• Abh.: TP22 ✅ (GC-Deploy-Pipeline). Verwandt TP3.2 (docs/wifi-p750w-coverage-and-map.md), TP29 (nutzt dieselbe Datenquelle als Sensor). Kein Blocker für irgendetwas.

TP29 — Anwesenheitserkennung fürs Energiesparen ▸ 💡 IDEE, noch nicht auf dem kritischen Pfad (angelegt 2026-08-21)

User-Formulierung (2026-08-21): „Personen im Haus orten mit BT (Shellys), WiFi und Radar. So kommen wir dem Ziel der Energieersparnis ohne Komfortverlust groß näher."

• Ziel: raumgenaue Anwesenheit als Eingangssignal für Heizung und Licht — sparen, ohne den typischen Komfortverlust („erst kalt, dann warm, wenn jemand da ist").
• 🔎 Der Entwurfsgedanke sind die komplementären Schwächen der drei Quellen — keine trägt allein:

  Quelle	erkennt	erkennt nicht
  BLE über die Shellys	grobe Zonen, billig, überall vorhanden	Menschen ohne getragenes Gerät; Raumgrenzen unscharf
  WLAN (Registration-Table am Manager: Gerät, AP, Signal)	wer mit Telefon da ist, inkl. AP-Zuordnung	Menschen ohne Telefon; Raum nur so genau wie die AP-Abdeckung
  mmWave-Radar	auch die stillsitzende Person ohne Gerät	braucht einen Sensor je Raum

• ✅ Was schon steht: Shellys vollständig auf VLAN30 (TP17 ✅), HA produktiv — und mit docs/tp6-monitor-core.sh existiert seit TP25 bereits ein Sammler, der die WLAN-Präsenzdaten am Manager mitschreibt (Gerät → AP → Signal, im Sekundentakt).
• ❓ Offene Fragen für die erste Session: Datenpfad ins HA (MQTT oder REST?) · Firewall-Regeln für neue Sensorik (TP5 ist deny-by-default, jeder neue Dienst über eine VLAN-Grenze braucht eine Regel) · Aufbewahrung und Privatsphäre der Ortsdaten · ob Radar-Sensoren auf dirtyvader-iot laufen oder eigene Segmentierung brauchen.
• Abgrenzung: TP25 misst den Funk, TP29 nutzt ihn als Sensor — dieselbe Datenquelle, anderes Ziel. Die Raumkarten aus TP25 sind für TP29 direkt verwertbar: sie sagen, wie genau die WLAN-Quelle einen Raum überhaupt auflösen kann.
• Abh.: keine harten. Profitiert von TP25 (Abdeckung/AP-Zuordnung) und TP11 (Monitoring), wenn es dahin kommt. Kein Blocker für irgendetwas.

TP30 — Credentials: neu setzen & rotieren (Sammelbecken) ▸ 🔜 ANGELEGT 2026-08-24, bewusst GEBÜNDELT gegen Projektende

User-Entscheid 2026-08-24: „ich würde gerne daraus einen eigenen punkt machen. ich bin mir sicher, dass es noch öfters passwörter zu rotieren geben wird. das machen wir dann alles gegen projektende." — nachgeschärft am selben Tag: „tp30 wird unser sammelbecken für credentials, die neu gesetzt werden müssen", und TP17.2 wandert hierher.

📥 Scope ist damit breiter als „Rotation": jedes Credential, das neu gesetzt werden muss — Erstvergabe (bisher gar keins vorhanden, z.B. Shelly SetAuth) oder Rotation (Wert verbrannt/abgelaufen). Die Trennung ist für die Priorität wichtig, für die Arbeit nicht: der Kostentreiber ist in beiden Fällen derselbe — die Konsumenten, nicht das Setzen. Neue Credential-Aufgaben kommen ab jetzt hier hinein, nicht als eigenes TP.

Warum ein eigener TP und nicht vier verstreute Follow-up-Zeilen: die Rotationen teilen sich Werkzeug, Fallen und vor allem den teuren Teil — den Konsumenten (HA, Nautobot, MikroMCP, ~/.secrets). Wer sie einzeln macht, zahlt den Re-Auth-Aufwand mehrfach. Gebündelt ist es ein Durchgang je Gerät. Deshalb steht hier die Liste, nicht der Termin.

• Auslösekriterium (statt Datum): wenn die offenen TPs abgearbeitet sind bzw. Christoph das Projekt schließt. 🔴 Harte Ausnahme, die den Termin vorzieht: ein neuer Leak, ein fremdzugängliches Gerät oder ein Personenwechsel — dann sofort und einzeln, nicht gebündelt.

#	Credential	Umfang	Anlass	Vorarbeit	Preis der Rotation
1	MikroTik admin	core · branch · ap1 · ap2 (ein geteilter Wert)	🔴 zweimal in ein Transkript geraten (2026-08-22 via sshpass -p; 2026-08-23 durch einen Enumerationsfehler)	✅ Etappe 1 durch (s.u.)	nach Etappe 2 nur noch ~/.secrets/credentials.env + ~/.claude.json + MikroMCP-Neustart
2	IoT-WLAN-PSK (sec-iot)	dirtyvader-iot, 26 Clients	steht im Klartext im TP17-Text ⇒ auch in der Git-Historie; Redigieren holt ihn dort nicht raus	Hebel multi-passphrase am Core verifiziert vorhanden, Tabelle leer	23 Shellys per Skript + 3 von Hand (.249 NSPanel Pro, .244 Nuki Bridge, .227 SwitchBot)
3	Shelly-Gerätepasswort (vormals TP17.2)	23 Shellys	Härtung (bisher keine Auth auf den Geräten)	✅ Werkzeug fertig (migrate.py cmd_auth + Digest-Fallback)	je Gerät ein HA-Re-Auth-Flow — das ist der Aufwand, nicht SetAuth
4	CF-Access-Service-Token (CF_API_TOKEN)	Cloudflare-Zugang, s. TP14.4	⏳ läuft am 2027-01-09 ohnehin ab — harter Termin, unabhängig vom Projektende	Runbook liegt (tp14.4-cf-access-token-runbook.md)	Token neu ausstellen + ~/.secrets nachziehen; account-owned, anderer verify-Endpoint

ℹ️ #3 war bis 2026-08-24 TP17.2 und ist jetzt vollständig hier (s. Detailabschnitt unten) — es benutzt denselben Geräte-Durchgang wie #2, ein Reboot statt zwei. #4 gehört sachlich zu TP14.4, das als TP bestehen bleibt (dort steckt das CF-Access-Profil, nicht nur der Token).

Posten #1 im Detail — MikroTik admin: Radius, Etappe 1, Etappe 2

Am 2026-08-24 aus den Follow-ups hierher gezogen — Text unverändert übernommen.

Vorgeschichte des Entscheids (Stand bis 2026-08-23, User: „machen wir, aber erst später"): ⏭️ Nachgelagert seit 2026-08-23: erst TP17.1, dann rotieren. Revidiert noch am selben Tag (User): beides läuft PARALLEL. Der Passphrase-Override je MAC (s.u.) macht den Flag-Day überflüssig, damit war die Reihenfolge nie technisch nötig — nur ökonomisch. Regel für die Parallelität: ein Gerät, das ohnehin auf Thread/Zigbee wandert, bekommt den neuen PSK gar nicht, sondern nur einen Übergangs-Eintrag in der access-list. ⚠️ Der Entscheid betrifft beide Passwörter: der IoT-WLAN-PSK steht im Klartext im TP17-Text (Archiv) und damit auch in der Git-Historie — bleibt auf User-Entscheid 2026-08-23 vorerst unverändert, weil Redigieren ihn nicht aus der Historie holt und Rotieren heute ~22 Shellys kostet. Nach TP17.1 sind es deutlich weniger. 🔴 Hinfällig seit 2026-08-23: TP17.1 ist verworfen — die Geräte bleiben WLAN-Clients, es werden also nicht weniger. Die Rechnung „~23 Shellys + 3 Fremdgeräte" gilt unverändert. Anlass: das Core-Passwort ist bei einer Debug-Ausgabe im Klartext in ein Sitzungstranskript geraten. Ursache war sshpass -p, das es in die Kommandozeile schreibt — sichtbar in ps und in jedem argv-Trace.

🔑 Radius-Befund 2026-08-23: das Admin-Konto teilen sich FÜNF Konsumenten

Vor dem Rotieren erhoben — das ist deutlich mehr als „vier Geräte + eine Datei":

Halter	Nachziehen
~/.secrets/credentials.env	Datei
~/.claude.json (MikroMCP-Env, ROUTER_*/CRS326_*)	JSON + MCP-Neustart
Nautobot-Stack NAUTOBOT_ROUTEROS_USERNAME/PASSWORD	Stack-Datei + Portainer-Redeploy auf der DS923
HA: VIER mikrotik-Integrationen (.99.1/.2/.11/.12, 40 device_tracker)	🔴 supports_reconfigure: false — NICHT skriptbar, 4× Re-Auth von Hand
Repo-Skripte (routeros/*.py, nautobot/*.py, docs/tp*.sh)	ziehen aus ~/.secrets → automatisch

⇒ User-Entscheid 2026-08-23: Konten trennen statt ein Passwort teilen. Nicht das Rotieren ist das Problem, sondern dass ein einziges admin von fünf Stellen benutzt wird — jede Rotation kostet sonst wieder vier Re-Auths und einen Stack-Redeploy.

✅ Etappe 1 DURCH (2026-08-23): dedizierte Service-Accounts auf allen vier Geräten

Rein additiv, kein laufender Dienst berührt. Vorher existierte nur admin (Gruppe full).

Gruppe	Policy	User	Zweck
grp-ha	read,api,rest-api,test	ha	HA-Mikrotik-Integration, lesend über API 8728
grp-nautobot	ssh,read,write,test,sensitive	nautobot	Golden Config über SSH/Netmiko (Backup und Deploy)

Passwörter: MIKROTIK_HA_PASS / MIKROTIK_NAUTOBOT_PASS in ~/.secrets/credentials.env (32 Zeichen, je Dienst eigen, geräteübergreifend gleich). 🔒 Angelegt über ein Skript, das die Werte aus der Datei liest — bewusst nicht über manage_user, dessen password-Parameter im Sitzungstranskript landen würde.

Abnahme, auf allen vier Geräten geprüft:

• ha liest (identity, dhcp-lease — am Core 59 Einträge, genau was das Device-Tracking braucht), Schreibversuch wird abgewiesen.
• nautobot meldet sich per SSH an und exportiert; kein REST (bewusst kein rest-api in der Policy).
• 🎯 Der Export von nautobot ist byte-identisch zu dem von admin (391/56/87/87 Zeilen je Gerät) ⇒ die GC-Compliance driftet beim Umstellen nicht. Das war das Hauptrisiko dieser Etappe.
• /user wird von keiner ComplianceRule abgedeckt ⇒ die neuen Konten erzeugen selbst keinen Drift.

⏭️ Etappe 2 offen — die Konsumenten umhängen, DANN admin rotieren

1. Nautobot auf nautobot umstellen (Stack-Env + Portainer-Redeploy), GC-Backup-Lauf als Abnahme.
2. HA: die vier mikrotik-Einträge auf den ha-User bringen. ⚠️ Reconfigure ist nicht skriptbar; Entfernen-und-neu-Anlegen wäre skriptbar, riskiert aber die 40 device_tracker-Entity-IDs (sie leiten sich aus der MAC ab, kämen also gleich zurück — aber erst nachdem die alten Registry-Einträge weg sind, sonst hängt HA ein _2 an; dieselbe Falle wie beim Shelly-Rename).
3. Erst danach admin rotieren — dann berührt es nur noch ~/.secrets + ~/.claude.json.

🔴 Eigener Fehler, protokolliert: beim Erheben des Radius hat ein json.dumps-Aufruf über ~/.claude.json das ap1-Passwort im Klartext ins Transkript geschrieben. Da alle vier Geräte dasselbe admin-Passwort teilen, ist es derselbe Wert, der am 2026-08-22 bereits verbrannt ist — keine neue Expositionsklasse, aber ein zweiter Beleg dafür, dass die Rotation fällig ist. Merkregel: Secrets-Enumeration gibt nur Schlüsselnamen aus, nie Werte — auch nicht abgeschnitten.

✅ Vorbedingung erfüllt, geprüft 2026-08-23: alle vier Skripte laufen auf sshpass -e (tp6-marker/server.py, tp6-monitor-core.sh, tp25-walk-messung.sh, tp25-pin-s22.sh) — die frühere Notiz, zwei davon hätten die Schwäche noch, war veraltet. Übrig blieb nur CLAUDE.md, das sshpass -p weiterhin aktiv als Reboot-Weg empfahl — am 2026-08-23 auf sshpass -e korrigiert. Damit ist die Rotation ohne Rückfallgefahr fahrbar. Weg: manage_user set-password (⚠️ /user set* ist per Deny-Policy blockiert), danach ~/.secrets/credentials.env (ROUTER_*_PASS/CRS326_*_PASS) und ~/.claude.json nachziehen. Es ist ein Passwort für alle vier Geräte — die „Überlebensversicherung" aus CLAUDE.md.

• 🔎 Nachtrag 2026-08-23 (Recherche-Session, read-only — kein Eingriff): der PSK in der Doku ist noch der LIVE konfigurierte. Gegengeprüft am Manager crs326-core (/interface wifi security, Profil sec-iot → cfg-iot → SSID dirtyvader-iot, datapath.vlan-id=30, wpa2-psk,wpa3-psk) — und zwar per Fingerprint statt Klartext (Länge + drei Zeichenpaare), damit der Wert nicht ein zweites Mal in ein Transkript wandert. Diese Methode ist die Merkregel daraus: einen Verdacht auf Übereinstimmung prüft man mit Stichproben, nicht durch Ausgeben.

• ✅ User-Entscheid 2026-08-23 zur Git-Historie: belassen, im Nachtrag dokumentieren — kein git filter-repo. Begründung trägt: genau eine getrackte Fundstelle (Archiv), drei Commits (e76289c Ersteintrag 2026-07-11, f0d1ff9 08-08, 7ee64b5 Doku-Split 08-23), Remote ausschließlich gitea.emsenhuber.net, ein lokaler Klon. Eine History-Rewrite hätte hier also nichts gerettet, was nicht ohnehin nur auf der eigenen Infrastruktur liegt — und den Preis (alle Hashes neu) für nichts bezahlt.

• 📊 Warum die Rotation heute teuer ist — live gemessen 2026-08-23: 26 der 27 WLAN-Clients des gesamten Netzes hängen auf dirtyvader-iot (dirtyvader-main 1, MEDIA/UNTRUSTED/GUEST je 0). VLAN30 führt 41 Leases/Reservierungen (5 aktuell bound, der Rest sind statische Reservierungen ausgeschalteter Geräte). Neben den ~26 Shellys hängen dort P750W (Drucker), Airfryer (espressif, .180), SwitchBot floor-lamp, Twinkly .228, DTUBI .8, SONOFF-NSPanelPro und ein iPhone .177. ⇒ Ein Passwortwechsel ist heute eine Batch-Aktion über ~26 Geräte, und das ist genau die Rechnung, die TP17.1 verkleinert.

• 🔧 Zwei Umsetzungshinweise fürs spätere Rotations-Paket: (a) mcp/shelly/migrate.py hat kein Rotate-Kommando (nur migrate/deanchor/auth/ table) — es bräuchte eine kleine Variante über denselben set_sta-Pfad. (b) Ein Flag-Day ist vermeidbar: RouterOS 7 kann in /interface wifi access-list Passphrase-Overrides je MAC. Also neuer PSK aufs Profil, Altgeräte übergangsweise per MAC mit dem alten weiter, danach die Liste leeren. 💡 Nebeneffekt: der TP25-Befund „keine access-list" bekäme damit endlich einen Zweck — und seit dem 08-23 gibt es die ComplianceRule wifi-access-list, die Einträge dort auch sichtbar macht.

• Mitzuziehen bei der Rotation (legitime, gitignorete Ablagen desselben Werts): ~/.secrets/credentials.env (+ .bak-20260808), routeros/.secrets/wlan-psks.env, mcp/shelly/.env.

• CF-Access-Service-Token — Rotationsposten #4, am 2026-08-24 aus den Follow-ups hierher gezogen (stand dort als „TP14.4 — CF-Access-Service-Token rotieren"). Sachlich gehört er zu TP14.4 (CF-Access-Profil für Claude, Runbook docs/tp14.4-cf-access-token-runbook.md); hier steht er, damit die Rotationsliste vollständig ist. ⚠️ Der CF_API_TOKEN läuft ohnehin 2027-01-09 ab — spätestens dann ist dieser Posten fällig, unabhängig vom Projektende.

Posten #3 im Detail — Shelly-Gerätepasswort (SetAuth), vormals TP17.2

Am 2026-08-24 als eigenes TP aufgelöst und hierher gezogen — Text unverändert übernommen.

User 2026-08-23: „außerdem haben wir einen punkt, um die shellys mit einem pwd zu schützen." Damit ist der Zurückgestellt-Status von 2026-07-13 aufgehoben. Begründung der Kopplung: die PSK-Rotation fasst ohnehin jeden Shelly an und rebootet ihn — SetAuth gehört in denselben Durchgang, ein Reboot statt zwei.

✅ Werkzeugseitig ist nichts zu bauen: mcp/shelly/migrate.py hat cmd_auth (setzt Shelly.SetAuth mit SHA-256-ha1 gegen die Geräte-realm, Dry-Run als Default), und _rpc hat einen Digest-Auth-Fallback auf 401 mit SHELLY_DEVICE_PW.

🔴 Der teure Teil ist nicht SetAuth, sondern Home Assistant. Mit aktiver Auth verlangt die Shelly-Integration je Gerät einen Re-Auth-Flow — bei 23 Geräten ist das der Aufwand, und genau der Grund für die frühere Einstufung als „Kosmetik". ⇒ Erst an EINEM Gerät machen und den HA-Aufwand messen (Vorschlag s15 technik_pve, RSSI −36, unkritisch), bevor der Rest folgt. Sonst bündelt man ein ungemessenes Risiko in eine 23-Geräte-Aktion.

Ursprünglicher Text (historisch)

• Was: je Gerät Shelly.SetAuth (User admin, realm-individueller ha1 = sha256("admin::"), einheitliches Klartext-PW) via mcp/shelly/migrate.py auth --go. SHELLY_DEVICE_PW liegt in mcp/shelly/.env (gesetzt, len 13). Runner + Digest-Auth-Fallback in _rpc fertig.
• Warum zurückgestellt: rein kosmetisch/Härtung; bricht die HA-Shelly-Integration, bis pro Config-Entry (22×) das Credential neu eingetragen ist → disruptiv, kein Mehrwert im abgeschotteten IOT-VLAN. Erst nach dem Netz-Teardown (TP19) neu bewerten.

🔴 Neues Leak-Ereignis 2026-08-24 — der IoT-PSK ist erneut exponiert

Beim 5-GHz-Umfeldscan für TP25 wurde mcp__mikromcp__list_wifi_interfaces gegen den Manager gefahren, um die cap-wifiN-Zuordnung zu bestimmen. Das Tool gibt security.passphrase aller Profile im Klartext zurück — damit stehen alle fünf WLAN-Passphrasen (main, iot, media, untrusted, guest) in einem Sitzungstranskript. Kein Werkzeug hat versagt; es war das falsche Werkzeug für eine Kanalabfrage. Betrifft Posten #2 (IoT-PSK) und zusätzlich vier bisher unverbrannte Passphrasen. ⚖️ Nach der „harten Ausnahme" oben ist das ein Vorziehgrund — Entscheidung gehört Christoph. Gegenargument, das dieselbe Rechnung wie am 08-23 ergibt: der IoT-PSK lag ohnehin schon im Klartext in der Git-Historie, neu exponiert sind vor allem main/media/untrusted/guest — und die kosten beim Rotieren wenige Clients, nicht 26. ⇒ main und guest wären billig und einzeln machbar, unabhängig vom gebündelten Durchgang.

Fallen, die für jedes Setzen/Rotieren gelten (nicht neu erheben)

• 🔴 Kein Read auf /interface/wifi, wenn nur Kanäle/Interfaces gebraucht werden — list_wifi_interfaces liefert alle Passphrasen im Klartext mit (Leak vom 2026-08-24, s.o.). Feldauswahl benutzen oder /interface wifi channel print detail.
• 🔴 Niemals sshpass -p — schreibt das Passwort in die Kommandozeile, sichtbar in ps und in jedem argv-Trace. Genau so entstand Leak #1. -e hält es in der Umgebung des Kindprozesses. Der Repo-Stand ist bereits durchgängig -e.
• 🔴 Passwörter nie per MCP-password-Parameter setzen, sondern per Skript aus ~/.secrets (manage_user set-password; /user set* ist per Deny-Policy blockiert).
• 🔴 Keine Secrets-Enumeration im Transkript — das war Leak #2, ohne dass irgendein Werkzeug fehlerhaft war.
• 🔒 wifi-security ist als ComplianceRule grün, aber NICHT deploybar (Passphrasen stehen als <<REDACTED>> im Template). Ist-Stand für #2 immer per REST vom Gerät lesen (GET http://10.40.99.1/rest/interface/wifi/security), nie aus wlan-psks.env.
• ⚠️ CAPsMAN, für #2: eine Profiländerung wirkt erst nach remote-cap provision für beide APs — und die Abnahme ist eine frische DHCP-Lease je SSID, nicht die Registration-Table.
• ⚠️ Für #2 zuerst multi-passphrase gegen WPA3/SAE testen — auf einer Wegwerf-SSID, nie an dirtyvader-iot. sec-iot fährt wpa2-psk,wpa3-psk; trägt multi-passphrase SAE nicht, sperrt man 26 IoT-Geräte auf einmal aus, inklusive Nuki und NSPanel.
• ⚠️ s1/s2/s3 sind ausgesteckt und kommen im Dezember mit dem alten PSK zurück — der Übergangs-Eintrag muss sie überleben oder sie werden bei Rückkehr von Hand nachgezogen.
• 🔴 HA- und Repo-Nummerierung der Shellys weichen ab (s10, s17) — immer über MAC/IP zuordnen, nie über die s-Nummer.
• Abh.: keine harten; #2 und #3 laufen sinnvollerweise in einem Geräte-Durchgang. Blockiert nichts. Die frühere Kopplung „erst TP17.1, dann rotieren" ist gegenstandslos — TP17.1 ist am 2026-08-23 verworfen, die Geräte bleiben WLAN-Clients.

TP31 — Reverse Proxy für innen und außen; cloudflared von sechs Knoten auf einen ▸ 🔜 GEPLANT 2026-08-25

Auslöser (User 2026-08-24): „ich weigere mich, für public applications 2 cloudflare container zu installieren. … ich habe [den Core] unter der prämisse gekauft, dass über diesen dann auch die public apps laufen können. wir wollten doch den core als single point of failure platzieren."

Der Vorwurf, fair geprüft

Eine schriftliche Zusage, dass die Public-Apps auf den Core wandern, existiert nicht — TP16.1 ist durchgehend auf den privaten Zugang zugeschnitten und hält mehrfach fest, dass „der cloudflared-Public-Teil unberührt blieb". Aber der Vorwurf trifft trotzdem etwas Richtiges: dasselbe Dokument begründet die gesamte Auswahl mit Christophs Prinzip — „Router = einziger SPOF, keine Abhängigkeit zu anderen Rechnern" — und niemand hat je geprüft, ob der öffentliche Strang ohne sechs Container auskommt. Keine Täuschung, aber eine ungeprüfte Annahme.

Die Lösung ist nicht „raus aus Cloudflare", sondern „ein Knoten statt sechs"

Caddy als Reverse Proxy für innen und außen, emsenhuber.net in beiden Richtungen, plus ein cloudflared als Tunnel-Endpunkt.

• ⚖️ Erst geprüft, dann verworfen: der Weg über dst-nat. Der Core hält 90.146.33.177 direkt ohne CGNAT, Liwest lässt eingehend alles durch (User: „hatte früher schon nginx hier laufen"), und Origin Rules (Ziel-Port, Free = 10 Regeln), die CF-HTTPS-Ports (443, 2053, 2083, 2087, 2096, 8443) sowie Authenticated Origin Pulls sind alle im Free-Tarif enthalten. Es ginge also ohne jeden Container.
• 🎯 Christophs Einwand ist der bessere Weg: „caddy muss so oder so. nachdem dieser vorhanden ist, fahren wir natürlich über zero trust apps. noch etwas sicherer, aber kein zusätzlicher knotenpunkt, der ausfallen kann." Der Tunnel spart drei Risiken auf einmal: keine angreifbare Origin-IP, keine CF-IP-Allowlist, kein DDNS als Voraussetzung (der TP10-Updater bliebe sonst zwingend).

Zielbild

Internet ─► Cloudflare (Access, WAF) ─► Tunnel »bf-public« ─► cloudflared auf ap1/ap2
WARP ─► cf-mesh (nativ am Core, kein Container) ─┐
LAN  ─► Split-Horizon-DNS ───────────────────────┴─► Caddy (LXC 130, 10.40.20.40)
                                                      └─► alle Dienste per Host-Header

Öffentlich bleiben vier: vw (Bitwarden-Clients), hass (Companion-App), n8n (Webhooks Dritter), gitea (Access nur für die Web-UI, Git-/API-Pfade daran vorbei ⇒ Push ohne WARP bleibt). Alles andere ist intern; 19 Ingress-Zeilen über drei Tunnel werden EINE Catch-all-Regel auf Caddy.

Wo cloudflared läuft — und warum die APs (live gemessen 2026-08-24/25)

Gerät	Arch	Flash frei	RAM frei	Container?
ap1 / ap2 (hAP ax²)	arm64	95 MB / 128 MB	690 MB / 1 GB	✅ ja
crs326-core	arm 32-bit	2,9 MB / 16 MB	512 MB	❌ nie

• ✅ Christophs Argument, das den Ausschlag gibt: „cf auf den aps hat den vorteil, dass wir gegenüber unseren hosts/container nicht blind sind." — Der AP ist eine eigene Maschine, kein Docker-Host; die macvlan/ipvlan-Blindheit kann dort prinzipiell nicht auftreten. Kein anderer Ort hat das. 💡 Daraus folgt eine Reserve: fällt Caddy aus, kann derselbe Connector über eine zweite Ingress-Regel direkt auf ein, zwei kritische Backends zeigen.
• 🔴 Ehrliche Einschränkung: cloudflareds einziges Origin ist Caddy. Solange Caddy auf pve liegt, kauft ein Connector auf dem AP Hardware-Diversität, aber keine Verfügbarkeit — fällt pve aus, ist alles weg. Der echte Gewinn kommt erst mit caddy-bf2 (LXC 131).
• Caddy oder AGH zusätzlich auf die APs? Nein. 95 MB minus RouterOS-Reserve fürs eigene .npk (~20 MB) = ein Container pro AP. Kriterium, das auch künftig trägt: auf die Infrastruktur darf, was sich selten ändert und wenig schreibt — cloudflared ja (Config liegt in Cloudflare, schreibt nichts); Caddy nein (Caddyfile ändert sich bei jedem neuen Dienst); AGH nein (Query-Log schreibt dauernd → NAND-Verschleiß).
• ⚠️ Preis: container verlangt eine device-mode-Änderung mit physischer Bestätigung am Gerät (ap1 Technik UG, ap2 Technik OG). Und der AP bekommt eine zweite Rolle neben dem WLAN.

Umsetzung

1. ✅ ERLEDIGT 2026-08-25 — Leichen gelöscht: 120 adguard-bf1, 121 adguard-bf2, 128 nginx-proxy-manager, 129 caddy, 130 pihole1, 131 pihole2 — alle waren stopped, onboot: 0 und hingen konfigurativ noch am toten VLAN1 (10.40.41.116/.117, GW .41.254). pct destroy --purge hat 120 und 128 zugleich aus dem Backup-Job entfernt. Alle 72 PBS-Snapshots radiert — sieben davon waren in PBS als protected markiert und mussten erst über pvesh set …/content/<volid> --protected 0 entschützt werden (User-Freigabe 2026-08-25). Gegenprobe: 0 Snapshots zu allen sechs IDs. ⚠️ Merkregel: pvesm free scheitert an geschützten Snapshots mit „cannot remove protected snapshot" — und zwar stillschweigend, wenn man den Fehler nicht ausliest. Wer nur die Erfolgszähler betrachtet, hält ein halb erledigtes Aufräumen für fertig.
2. ✅ ERLEDIGT 2026-08-25 — LXC 130 caddy-bf1 steht: Debian 13, VLAN20 tag=20, 10.40.20.40/24, GW/DNS 10.40.20.1, onboot: 1, startup order=10 (Core-Stufe nach TP32), 4 GB / 512 MB, 2 Cores. In den Backup-Job backup-6dcf5c10-610f aufgenommen. Caddy v2.11.4 installiert, Modul dns.providers.cloudflare verifiziert vorhanden. Egress geprüft (DNS, HTTPS, CF-API) — TP5 lässt VLAN20 nach draußen.
3. ⏳ Konfiguration liegt, Dienst läuft noch nicht — es fehlt genau ein Credential. caddy/Caddyfile im Repo (17 Sites: 4 öffentlich vw/hass/n8n/gitea, 13 intern inkl. der vier MCP-Endpunkte und drei HTTPS-Backends mit tls_insecure_skip_verify), Syntaxprüfung läuft durch. Zertifikate ausschließlich per DNS-01, damit auch rein interne Namen gültige Zertifikate bekommen. 🔑 Offen: das eng geschnittene Token — Zone:DNS:Edit, Zone-Resource auf emsenhuber.net begrenzt, nicht das account-weite CF_API_TOKEN ⇒ Posten für TP30. Ablage als CF_DNS_API_TOKEN in ~/.secrets/credentials.env, Ausrollen per caddy/deploy.sh — das liest den Wert von dort und schreibt ihn in die Container-Env, ohne ihn je auf stdout oder in eine Kommandozeile zu bringen (dieselbe Regel wie sshpass -e).
4. Split-Horizon → ✅ ENTSCHIEDEN 2026-08-25: in AdGuard, zusammen mit TP23 Stufe 2. Begruendung des Users: nichts zweimal bauen. Konsequenz, die man kennen muss: AdGuard wird damit vom Nebendarsteller zum Resolver des Standorts — heute liefert der DHCP in allen sieben VLANs dns-server = <VLAN>.1, also den Core; AGH auf 10.40.20.16 bekommt niemand. ⇒ Der Schritt ist groesser als „ein paar Eintraege": er verschiebt die DNS-Aufloesung des ganzen Hauses vom grundsoliden Core in einen Container. 🔑 Deshalb als Paar bauen — TP32 reserviert 110/111 fuer DNS, und die geloeschten Altlasten hiessen nicht zufaellig adguard-bf1/adguard-bf2: die Redundanz war urspruenglich schon einmal geplant. Ein einzelner AGH waere ein DNS-SPOF auf pve.
5. Tunnel bf-public + Connectoren auf ap1/ap2, CNAMEs umhängen (n8n → gitea → hass → vw).
6. Abbau: bf-nas/bf-pve/bf-mm löschen, sechs Container weg, SSH-Browser-Rendering entfällt, MCP-Clients auf FQDN umstellen (~/.claude.json spricht heute 10.40.20.105:9583 und 10.40.20.173:3000 roh; n8n-mcp/gitea-mcp kommen dabei wieder in Betrieb).

✅ Stand 2026-08-25 nach dem Bau — Caddy laeuft, zwei Backends fielen dabei auf

17 von 17 Zertifikaten per DNS-01 von Let's Encrypt geholt, Dienst active+enabled, Proxy-Funktion gegen den Host-Header verifiziert: nautobot 302 · gitea 200 · pve 200 · portainer 200. caddy/deploy.sh laeuft End-to-End (Token wird aus ~/.secrets gelesen, per Fingerprint gegengeprueft: eigenes Token, nicht das account-weite).

🔴 Fund: grafana war seit Langem tot — und Cloudflare Access hat es maskiert. LXC 104 alpine-grafana stand auf stopped und konfigurativ noch auf VLAN1 (10.40.41.109); die CF-Ingress-Zeile zeigte auf 10.40.20.109:3000 — eine Adresse, die es fuer Grafana nie gab. Im FQDN-Smoke-Test lieferte grafana.emsenhuber.net trotzdem ein sauberes 302 — das war der Access-Login, nicht der Dienst. ⚠️ Das ist exakt die Falle aus TP16.3 §8, diesmal in freier Wildbahn: ein Statuscode vom oeffentlichen FQDN sagt nichts ueber das Origin, solange Access davor steht. Ein toter Dienst sieht monatelang gesund aus. ⇒ Caddy-Zeile entfernt (16 Sites), LXC 104 zerstoert und aus dem Backup-Job genommen — die 14 PBS-Snapshots bleiben bewusst stehen, sie sind die einzige Kopie etwaiger Dashboards. Wiederaufbau spaeter als eigener Punkt, dann nach TP32-Systematik.

🟡 hass liefert 400 — der bekannte offene Punkt aus TP16: Home Assistant braucht 10.40.20.40 in http.trusted_proxies plus use_x_forwarded_for: true, sonst weist es den neuen Proxy ab. Gehoert vor die CNAME-Umstellung von hass.

🎯 Kernabnahme: WAN trennen, dann alle Dienste per FQDN. Das ist die Autarkie, um die es geht. ⚠️ Preis, offen benannt: mit Split-Horizon greift Access innerhalb des Netzes nicht mehr; dort tragen TP5-Segmentierung und die App-eigene Auth.

HA-Ausblick (nicht Teil der Umsetzung)

Es bleibt bei Caddy — zustandslos bis auf den Zertifikatsspeicher, identisches Caddyfile je Instanz, versionierbar; NPM hätte eine Datenbank, die man mitreplizieren müsste. 🔴 Prinzip für vw: der Eingang darf nicht klüger sein als die Datenbank. TP20.1 sieht manuelles Promote vor. Zwei Connectoren auf verschiedene Caddys an verschiedenen Standorten würden die Hälfte der Schreibzugriffe auf einen read-only Standby schicken — das #1033-Muster, diesmal mit Datenverlust statt 530ern. Automatisches Ingress-Failover erst, wenn der DB-Teil es trägt (User: vertagt bis TP20.1 Phase 1+2 laufen).

• Abh.: TP32 (Nummern/IPs — vergibt 130/.40), TP16.1 ✅ (Mesh), TP23 Stufe 2 (Split-Horizon-Ort). Löst ab: TP16 (reziprokes HA) und TP16.2 (der vw-bypass-Strang bekommt mit Caddy + CF davor einen anderen Schutz). TP16.3 ist der Pilot dieses TP.
• 📋 Vollständiger Plan mit allen Abwägungen: ~/.claude/plans/expressive-pondering-clarke.md

TP32 — Nummern- und Adress-Systematik ▸ 🟢 KONZEPT STEHT (2026-08-25), Startreihenfolge bereits repariert

User-Auftrag 2026-08-24: „du/ich sollst in der lage sein, selbstständig nach einem vorgegebenen system freie ips vergeben zu können … und diese systematik findet sich in anderen netzen künftig auch wieder" · „ich meine 100 sollte künftig für die core services stehen."

Eigener TP, weil es eine Konvention ist, kein Bauteil — TP31 ist ihr erster Kunde. Regel: Bestand bleibt, wo er ist; jeder NEUE Gast folgt der Systematik.

🔑 Ein gemeinsamer VMID-Raum für VMs und LXCs. 100 haos und 330 RaspberryMatic sind VMs — die Klasse bestimmt die Nummer, nicht die Virtualisierungsart.

Kreis	Klasse	heute dort (VM kursiv)
100–199	Core / Infrastruktur	108 mcast-relay
200–299	Daten / DBs (Precious-Tier)	(105, 106, 107, 302 → später hierher)
300–399	Security / Identity	—
400–499	Platform / Runtime	✅ 400 docker passt bereits
500–599	App-Services / Smart Home	101, 102, 112, 150, 100, 330 → später hierher
600–699	Business / ERP	201 openproject
700–799	KI / ML	—
800–899	Dev / R&D / Test	—
900–999	Ephemeral / Scratch	wird ungefragt gelöscht

Zehnerschritte innerhalb eines Kreises („Respektabstand", User), damit Instanzen und Nachbarn Platz haben: 100–109 netznah · 110–119 DNS · 130–139 Reverse Proxy · 150–159 Monitoring · 170–179 PKI/Zeit. ⇒ AGH 110, Caddy 130.

Letztes Oktett je /24 — gilt in jedem VLAN, an jedem Standort:

Oktett	Rolle	Anker heute
.1–.9	Gateways / L3	.1 je VLAN ✅ · 99.1 core, 99.2 branch ✅
.10–.29	physische Hosts (Storage, Hypervisor, APs)	NAS 20.10 ✅ · APs 99.11/.12 ✅
.30–.99	virtuelle Core-Services, Zehnergruppen wie oben	DNS .3x · Ingress .4x · DBs .5x · Security .6x · Monitoring .7x
.100–.199	App-Services
.200–.249	DHCP-Pool
.250–.254	VIPs / Relays

🔑 Der Merk-Trick: die Zehnergruppe im Oktett spiegelt die der VMID. 110 agh → .3x, 130 caddy → .4x. Wer eine Zahl kennt, kennt die Klasse der anderen.

Warum der Bestand anders aussieht — er war nicht falsch, nur auf einer anderen Achse

User 2026-08-25: „zuerst war haos, welches mit 100 den nummernkreis für iot eröffnet hat. und die anderen … gehörten zu ha, daher 1xx. erst später habe ich erfahren, dass die nummer die startreihenfolge definiert." ⇒ Der Bestand gruppiert nach Zugehörigkeit, die neue Systematik nach Klasse. Beide Achsen sind legitim; die zweite ist die, die das System auswertet. Der alte 1xx-Block ist der Smart-Home-Block und wandert später als Gruppe nach 5xx.

✅ ERLEDIGT 2026-08-25: die Startreihenfolge war nachweislich falsch

🔴 Und der Hebel ist NICHT die VMID. Drei Gäste hatten ein explizites startup: order= (101 iob-master 110, 102 mqtt5 120, 100 haos 125), alle übrigen keines. Proxmox startet erst alle Gäste mit order=, dann den Rest nach VMID — real lief also iob-master → mqtt5 → haos und erst danach platform-pg, mariadb, z2m25, docker. ⇒ Home Assistant startete vor seiner eigenen Datenbank.

Repariert (wirkt beim nächsten pve-Neustart):

order=	Stufe	Gäste
10	Core	108 mcast-relay
20	Daten	105 platform-pg (up=15), 302 mariadb (up=15), 106 influxdb2, 107 redis
30	Platform	400 docker (up=20)
40	Broker / Funk	102 mqtt5 (up=10), 112 z2m25, 330 RaspberryMatic
50 / 51	Anwendungen	101 iob-master, 100 haos, 150 iob-exposed

🎯 Die wichtigste Erkenntnis des TP: VMID = Klassifikation, startup: order= = Abhängigkeitsreihenfolge. Die Umnummerierung muss die Startreihenfolge gar nicht reparieren — das ist bereits erledigt, ohne eine einzige ID zu ändern. Die Nummernkreise sind damit reine Ordnung und Lesbarkeit, und der Bestand kann in Ruhe nachziehen.

• Offen: Migration des Bestands (Tabelle oben) — am Ende der Reise, nicht jetzt. Und die Kollision AGH will .30, dort sitzt Nautobot (.31 = nautobot-worker) ⇒ Vorschlag .36 als Interim, .30 erst nach dem Nautobot-Umzug in den App-Bereich. Fällt vor dem AGH-Neubau an.
• Abh.: keine. Blockiert nichts, aber TP31 vergibt bereits danach.

TP33 — Sonos aus der Ferne bedienen (VPN/WARP) ▸ 💡 IDEE, bewusst zurückgestellt (angelegt 2026-08-25, User-Entscheid „später entscheiden")

• Auslöser: beim Sonos-Fall vom 08-25 kam die Frage auf, ob die Player auch von unterwegs auffindbar sein sollen. Antwort für jetzt: nein, später entscheiden — hier nur festgehalten, damit die Begründung nicht verloren geht.
• 🔑 Der Kernsatz: SSDP und mDNS queren einen Tunnel nicht von selbst. Beides ist link-lokal (TTL 1 bzw. Multicast auf 224.0.0.251), ein WireGuard-/WARP-Tunnel ist ein Punkt-zu-Punkt-Interface ohne Broadcast-Domäne. Es bräuchte also dieselbe Relay-Bauart wie TP7.1, nur ein zweites Mal — ein Bein im Tunnel, eines in VLAN40 — plus die passende forward-Regel (TP5 ist deny-by-default).
• ⚖️ Warum zurückgestellt: echter Zusatzaufwand für einen Randfall. Steuern aus der Ferne geht heute schon über die Sonos-Cloud-App und über HA (cf-mesh/CF-Tunnel), beides ohne Discovery. Fehlt nur die Desktop-App von außen — dafür lohnt der zweite Relay-Strang derzeit nicht.
• ⚠️ Nicht mit dem Gegenteil verwechseln: mit aktivem WARP findet die App die Player auch lokal nicht — erwartbares Verhalten, kein Fehler (ref_warp_local_icmp_trap, Gotcha in CLAUDE.md). Wer den Fernzugriff baut, muss genau diesen Fall mit auflösen.
• Abh.: TP7.1 (Relay-Muster) ✅, TP16.1 (cf-mesh) ✅. Blockiert nichts.

---

---

Abgeschlossene Teilprojekte ▸ teilprojekte-archiv.md

34 abgeschlossene TPs liegen dort im Volltext, unverändert und mit eigenem Inhaltsverzeichnis. 📊 Für einen Statusbaum reicht diese Datei: die Tabelle unten nennt jedes archivierte TP, und die Zeile „✅ Durch (Fundament)" weiter unten führt sie noch einmal mit Abschlussdatum. Das Archiv muss dafür nicht geöffnet werden — es trägt die Begründungen, nicht den Status.

Kurzorientierung, wo was zu finden ist:

Thema	TPs im Archiv
Fundament / Fabric	TP1 ALLNET-Core (Gerät ausgebaut) · TP2/TP2.1 Omada (ausgebaut) · TP15 HW-Refresh CRS326 · TP21.1 Core-Cutover-Recovery · TP4 Router-Cutover (Rolle seit 08-08 auf dem Core)
WLAN	TP3 (historisch) · TP3.1 · TP3.2 · TP3.3 (in TP25 aufgegangen) · TP28 CAPsMAN auf dem Core · TP25-Langfassung
Firewall / QoS	TP5 deny-by-default · TP26 ip-firewall-filter unter Drift-Kontrolle · TP6 CAKE (geschlossen statt gebaut) · TP6.1 Upload-Priorisierung
Discovery / Media	TP7 mDNS · TP7.1 SSDP-Relay · TP7.2 HA↔Sonos
Hosts / Migration	TP14 (+.1/.2/.2a/.3/.5) VLAN20-Cutover · TP17 Shelly→VLAN30 · TP19 VLAN1-Retirement
Control-Plane	TP20 Platform-Postgres · TP21 Nautobot GC · TP22 Adoption + Compliance-Push · TP27 RouterBOOT 7.24 · TP-R Capabilities-Sweep
Zugang	TP10 Multi-Site-VPN (offen nur der DDNS-Updater, s. Follow-ups) · TP16.1 natives CF-Mesh
Verworfen	TP9 Gateway-HA (User-Entscheid 2026-08-08)

Reihenfolge / Abhängigkeiten

🎯 Kritischer Pfad (Stand 2026-08-23) — LEER

TP5 E1 ✅ ─► E2 ✅ ─► E2-Nachtrag ✅ ─► E3 Drop ✅ ─► E4 input+MGMT ✅ ─► E5 MAIN→IOT ✅ ─► TP6 ✅ GESCHLOSSEN

                        🎯 DER KRITISCHE PFAD IST LEER (2026-08-23).
              Das Projekt ist in seinem Kern fertig: deny-by-default steht, Golden Config
              steht, WLAN steht, VLAN1 ist weg, und TP6 ist beantwortet statt offengelassen.
              Was jetzt kommt, entscheidet Christoph — nichts blockiert mehr etwas.

➡️ Update 2026-08-22 (Sitzungsende): TP25 hat den Pfad seit dem 08-20 blockiert und ist im Kern erledigt — die Terrasse ist repariert, der Dead Spot weg, Fund E abgestuft. Damit ist TP6 wieder der einzige Punkt auf dem kritischen Pfad, und seine Prämisse ist inzwischen gemessen (tp6-praemisse-messrunbook.md §5): formal Fall B (+28…47 ms in der Senderichtung), aber durch sechs Lastphasen mit laufendem Videocall kein einziger Problem-Klick. Die nächste Sitzung entscheidet daher bauen oder begründet schließen — sie misst nicht neu. Übergabe mit den Sitzungszuschnitten: handoff-20260822-naechste-schritte.md.

🟢 Update 2026-08-23 (Endstand): TP6 ist beantwortet — und der kritische Pfad damit leer. Gebaut wurde, wie entschieden. Der erste Anlauf (/queue tree parent=vlan100) war wirkungslos, aber nicht aus dem zuerst notierten Grund: nicht der Switch-Chip, sondern die MikroTik-dokumentierte Regel, dass Interface-HTB bei hw-offloadetem out-interface nicht greift. Ueber parent=global + Mangle-Mark funktioniert CAKE einwandfrei (zaehlt 6 MB, drosselt 9,3 → 7,78 Mbit). Und genau deshalb ist das Ergebnis belastbar: die Latenz unter Last bessert sich trotzdem nicht — bei keiner Bandbreite, auch nicht bei 52 % der Linerate (42,4 / 43,3 / 44,0 / 44,6 ms). Der Puffer sitzt im DOCSIS-Uplink, nicht im Router. ⇒ TP6 schliessen: nicht mangels Nutzen, sondern weil das Werkzeug nicht an die Ursache reicht. Details im TP6-Abschnitt oben, Merkregeln in ref_queue_htb_platzierung_docsis.

🔴 Korrektur wenige Stunden spaeter (2026-08-23, TP6.1): die DOCSIS-Erklaerung oben ist FALSCH. Der Puffer sitzt nicht unabaenderlich im Uplink — er loest sich auf, sobald der Verkehr in getrennte Klassen faellt: NAS-Bulk priority=8 gegen interaktiv priority=1 bringt dieselbe Strecke unter derselben Saettigung von 40,8 auf 11,0 ms (−73 %). Der Fehler steckte in der Messmethode — Last und Messung liefen vom selben Host, ein Shaper kann eine Queue nicht priorisieren, in der nur eine Klasse liegt. ⇒ TP6 bleibt geschlossen (CAKE war das falsche Werkzeug), aber nicht aus dem dort notierten Grund. Der Rest steht in TP6.1 (Archiv) und in ref_queue_htb_platzierung_docsis.

📜 Die folgende Fassung stammt vom 2026-08-18 und ist erledigt — die Praemisse ist am 08-20/21 gemessen, TP6 am 08-23 geschlossen. Bewusst erhalten, weil sie zeigt, warum nicht gebaut, sondern zuerst gemessen wurde:

TP5 ist am 2026-08-18 abgeschlossen. Damit steht rechnerisch nur noch TP6 auf dem kritischen Pfad — 🟠 aber dessen Prämisse ist offen: eine Messung von 2026-06-16 (docs/call-quality-diagnosis.md) bescheinigt dem Netz bereits A/A+ und hält CAKE für „marginal". Der nächste Schritt ist deshalb ein Bufferbloat-Test gegen den heutigen Edge, nicht der Bau einer Queue. Fällt er gut aus, ist der kritische Pfad leer und das Projekt in seinem Kern fertig — dann entscheidet Christoph, was das neue Ziel ist. Alles andere läuft nebenher und blockiert nichts.

1. ✅ TP5 Etappe 1–4 — komplett durch (2026-08-16 bis 2026-08-18). Details im TP5-Abschnitt oben. Die Wartezeit-Position, die hier bis 2026-08-17 als eigener Schritt stand, ist eingeloest: statt eines mehrtaegigen Fensters wurde der Nachtrag aus einem dreieinhalbstuendigen Fenster abgeleitet und der Drop mit Auto-Revert plus weiterlaufender Log-Regel abgesichert. Die Vorbedingung D2 (iPhone .30.201) ist gegenstandslos: das Geraet hing dort bewusst zum Anlernen eines IoT-Geraets (User 2026-08-17). Wer im IOT-SSID sitzt, ist im selben VLAN wie das Geraet und beruehrt die forward-Kette gar nicht; fuer Ad-hoc-Zugriffe aus MAIN gibt es jetzt die selbstverfallende Gruppe jit-admin.
2. ✅ TP6 — QoS/CAKE ▸ GESCHLOSSEN 2026-08-23. Gebaut, gemessen, wieder ausgebaut. CAKE ist auf diesem Geraet baubar (Global-HTB + Mangle) und wirkt technisch — verbessert die Latenz unter Last aber bei keiner Bandbreite, auch nicht bei 52 % der Linerate. Der Puffer sitzt im DOCSIS-Uplink, nicht im Router (⚠️ widerlegt von TP6.1 am selben Tag — s. Korrektur oben). Queue und Template-Block sind entfernt, die ComplianceRule queue bleibt und bewacht den Abschnitt als leer. Damit ist der kritische Pfad leer. 💡 Aus dem Abschluss ist TP6.1 entstanden (Saettigung vermeiden statt Bufferbloat bekaempfen) — Christophs Gedanke, den NAS-Sync zurueckzuhalten. Steht als Vorschlag, nicht auf dem Pfad. ✅ Am selben Tag gebaut und gemessen: 40,8 → 11,0 ms. Das eigentliche Projektziel; keine offenen Blocker mehr. Korrigiert 2026-08-19: kein Blocker, aber eine offene Prämisse — der Satz oben und dieser Punkt widersprachen sich seit dem 18. Richtig ist: der nächste Schritt ist eine Messung, kein Bau. Runbook liegt bereit: docs/tp6-praemisse-messrunbook.md. Fällt sie A/A+ aus, wird TP6 geschlossen statt gebaut — dann ist der kritische Pfad leer und das Projekt in seinem Kern fertig.

Eine harte Reihenfolge-Regel dazwischen: TP5 darf die DNS-Bypass-Sperre erst schließen, wenn TP23s Ausnahme-Oberfläche steht — der bisherige Workaround „Client von Hand auf 1.1.1.1" ist genau dieser Bypass. Alles andere aus TP5 ist davon unabhängig und kann vorher laufen.

⚠️ Und eine zweite, aus TP16.1/TP16.3: der Drop braucht cf-mesh explizit — steht seit Etappe 2 als TP5-E2: mesh->LAN / LAN->mesh drin. Ohne diese zwei Zeilen sperrt Etappe 3 den Fernzugang aus, also genau den Weg, über den man den Fehler zurücknehmen wollte.

Follow-ups nebenher (blockieren nichts)

• TP25 — WLAN-Stabilisierung (NEU 2026-08-17): Audit durch, 6 Funde (2,4 GHz fährt 40 MHz statt der profilierten 20; ap2 sendet auf 5 GHz mit 9 statt 18 dBm, weil ch149 unter ETSI leistungsbegrenzt ist; 80 MHz kostet Randabdeckung; unzulässiger Channel-Override auf w2-iot; keine access-list; 5-Minuten-Takt bei IoT-Trennungen offen). Umsetzung in 6 Schritten, alles via GC. Übernimmt den offenen Rest von TP3.3.
• TP16.3 — cloudflared-Reduktion (NEU 2026-08-17): Recherche durch. Der Mesh ist schon der private Datenpfad (im TP5-Log mit 137 Zeilen belegt); Container braucht nur noch der öffentliche Ingress. Vorschlag: nautobot als Probe aus dem CF-Ingress nehmen.
• DoH-Cloudflare auf crs326-core ✅ erledigt 2026-08-18 (TP23 Stufe 1 = TP21.1 TODO 1).
• TP6.1 — Saettigung vermeiden ✅ LIVE 2026-08-23: 40,8 → 11,0 ms unter Last (−73 %). NAS-Sync weicht bei Last zurueck, ComplianceRule ip-firewall-mangle angelegt, 104/104.
• TP24 — DC-USV (seit 2026-08-16 eigener TP, aus TP15 herausgelöst).
• TP19 — VLAN1-Client-Retirement / cudy-Teardown ✅ geschlossen 2026-08-18 (VLAN1-ARP = 0). Die zwei Reste sind dorthin verschoben, wo sie hingehören: tote CF-Tunnel → TP16, HA-Portainer setup_retry → TP11.
• TP3.3 — WLAN-Coverage-Kur → in TP25 aufgegangen (2026-08-17). 802.11k/v ist repariert (08-13); Re-Walk + Dead-Spot-Kartierung laufen als Schritt 5 von TP25 — und zwar erst nach den Funkparameter-Fixes, weil vorher gemessene Werte wertlos sind.
• TP10 — DDNS-Auto-Updater für bf4.emsenhuber.net (auf dem Core möglich, device-mode erlaubt scheduler).
• 🔑 Alle Passwort-/Token-Rotationen laufen seit 2026-08-24 unter TP30 — Sammel-TP, gebündelt gegen Projektende (User-Entscheid). Dort steht die Rotationsliste (MikroTik admin, IoT-PSK, Shelly-Gerätepasswort, CF-Access-Token), der Radius der fünf Konsumenten, der Etappe-1-Abschluss und die Fallenliste. Etappe 1 ist durch, Etappe 2 wartet bewusst.
• Doku-Aufräumen (docs/doku-cleanup-session.md) ✅ abgeschlossen 2026-08-23. Punkte A–D (08-16), E (08-18/19) und F — der Split (08-23) sind durch: abgeschlossene TPs liegen jetzt in teilprojekte-archiv.md, TP25 ist von 394 auf ~100 Zeilen kondensiert, diese Datei ist von 2217 auf ~760 Zeilen. Die Regel dahinter bleibt gültig: ⚠️ während einer Doku-Session teilprojekte.md nicht parallel bearbeiten (in der Nacht auf den 18. viermal committet, das kollidiert sonst) — und ein TP wandert erst dann ins Archiv, wenn nichts mehr daran zu tun ist.

Nachgelagert / research-getrieben

TP8 (Identity/802.1X) · TP11 (Monitoring) · TP12 (IPv6) · TP13 (Botschafts-WLANs) · TP16.2 (Härtung bypass-Dienste) · TP18 (Garage-Objektspeicher) · TP20.1 (Vaultwarden → Platform-PG) · TP23 (DNS-Policy, s. Regel oben) · TP30 (Credential-Rotation — nicht research-, sondern termin-gated: gebündelt gegen Projektende, User-Entscheid 2026-08-24). (TP17.1 — Shelly Gen4 → Thread, aktiviert 2026-08-23 — läuft nicht hier, sondern im HA-Projekt ~/dev/ha-xstate; netzseitig ist nichts zu bauen. Es blockt bewusst die PSK-Rotation.) (TP16.1 stand hier bis 2026-08-17 fälschlich als offen — es ist seit demselben Tag ✅ abgeschlossen und steht unten unter „Durch" (Volltext im Archiv). Nachfolger ist TP16.3, das oben unter Follow-ups läuft.)

✅ Durch (Fundament — nicht mehr planen, nur nachschlagen)

📚 Alle folgenden TPs stehen seit 2026-08-23 im Archiv — im Volltext, mit Inhaltsverzeichnis. Diese Zeile bleibt als Landkarte: sie sagt, was fertig ist; das Archiv sagt, wie es dazu kam.

TP1 · TP2 · TP2.1 · TP3 (Rebuild 2026-08-08) · TP3.1 · TP4 (Rolle seit 08-08 auf dem Core) · TP7 · TP7.2 · TP10 (Kern) · TP14 (+14.1/14.2/14.2a/14.3/14.5) · TP15 · TP16 (Kern) · TP17 · TP19.1 · TP20 · TP21 · TP21.1 · TP22 · TP-R · TP3.2 (08-17) · TP5 (08-18) · TP7.1 (08-18) · TP19 (08-18) · TP23 Stufe 1 (08-18) · TP6 (08-23, geschlossen statt gebaut) · TP6.1 (08-23, Upload-Prio live) · TP26 (08-17) · TP27 (08-17/18) · TP28 (08-17, GC-Modell 08-18). Verworfen: TP9 (Gateway-HA, User-Entscheid 2026-08-08). Obsolet: Omada-PVID-Fix (User-Entscheid 2026-07-22 — „nie wieder aufgreifen").

📜 Historische Fassung dieses Abschnitts (bis 2026-08-14 fortgeschrieben, hier bewusst erhalten)

🎯 AKTUELLER KRITISCHER PFAD (Stand 2026-07-16, überschreibt die Reihenfolge unten): TP20 (Platform-Postgres) → TP21 (Nautobot) — Ziel: fertig vor CRS326-Produktivsetzung, spätestens Montag 2026-07-20. TP18 (Garage-S3) und die Komodo-Abhängigkeit wurden am selben Tag als Blocker entfernt/entkoppelt (s. TP20), um diese Deadline zu halten — beide werden später nachgezogen, nicht mehr vorher abgewartet. ➡️ Stand-Update 2026-08-08: TP20/TP21-Plattform steht, Core-Cutover (TP21.1) + WLAN-Rebuild (TP3) + VLAN20-Migration (TP14) sind durch. Neuer Rest-Pfad: TP22 (Device-Adoption + Compliance-Push) → TP5 (Deny-by-default) → TP6 (CAKE, das Ziel). Kleine Follow-ups davor: DoH-Cloudflare auf core, USV (TP24). ➡️ Stand-Update 2026-08-13 (Abschluss): TP22 ist DURCH (alle 5 Schritte; Fleet adoptiert, Deploy-Pipeline scharf, Datenmodell as-built, Secret-Handling entschieden) → kritischer Pfad jetzt: TP5 (Deny-by-default) → TP6 (CAKE). Kleine Follow-ups davor: DoH-Cloudflare auf core, DC-USV (TP24), Doku-Aufräumen (docs/doku-cleanup-session.md, vorbereitet 2026-08-14 — dieses Dokument beschreibt an mehreren Stellen noch die Topologie vor dem Core-Cutover). ➡️ Neu 2026-08-14: TP23 (DNS-Policy & Self-Service) hängt an TP5 — und zwar in beide Richtungen: TP23 braucht TP5s Firewall, TP5 darf aber die DNS-Bypass-Sperre erst schließen, wenn TP23s Ausnahme-Oberfläche steht (der bisherige Workaround „Client auf 1.1.1.1" ist dieser Bypass). Ebenfalls in TP5 gezogen: TP7.1 (SSDP-Reflector für die macOS-Sonos-App). Kabel core ether4→ether2 (Sideboard/TV) entfällt (2026-08-14): gelöst wurde am Port, nicht am Kabel (User-Vorgabe „Patchfeld-Nummerierung wird nicht wegen einer Config geändert") — ether4 steht seit 08-13 auf untagged VLAN40, End-to-End-Beweis am 08-14 erbracht, s. TP21.1 Punkt 4. Historisch: TP22 war das nächste Arbeitspaket — TP17 (Shelly-Migration) ist parallel dazu vollständig abgeschlossen (alle Shellys auf VLAN30, User-bestätigt). Grund für den Nautobot-First-Ansatz: Governance-Entscheid „Config exklusiv über Nautobot" (s. oben) macht Nautobot zur Voraussetzung für praktisch jede weitere Router-/Switch-Änderung. Die Punkte 3-4 unten (Omada-PVID-Fix etc.) sind obsolet (User-Entscheid 2026-07-22 — Omada spielt seit TP15-Korrektur keine Rolle mehr, nie wieder aufgreifen) — ganze Liste braucht mal eine Aufräum-Session, hier nur der aktuelle Fokus vorangestellt. ✅ TP16 (CF-Tunnel Round-Robin/macvlan-Host-Isolation → reziprokes 3-Tunnel-HA) KERN UMGESETZT 2026-07-10 (#1033 strukturell weg). Offen nur Access-Strang (WARP/vw) = user-gated. As-Built docs/cf-tunnel-mapping.md §10.

1. TP1 (GE8) → TP2 (Omada Controller). ✅ erledigt 2026-06-15.
2. TP4 (Router-Cutover L3-Infra + WAN-Edge). ✅ erledigt 2026-06-15 (L3) + 2026-07-01 (Edge-Cutover, FB physisch weg).
3. Jetzt: Omada-PVID-Fix — Omada Access-Profile korrigieren (PVID 10/20, untagNetworkIds bereinigen, sicher P3/P5/P6 zuerst), dann IP-Migration NAS/macmini/pve auf VLAN-Subnetze + DNS-Einträge updaten. IP-Migration NAS/pve = TP14 (NAS ✅ 2026-07-10, pve 🔜 Session B).
4. Dann: TP5 (Deny-by-default fertigziehen — Sonos-/HA-/mDNS-Holes + WAN-Input-Seal stehen bereits; TP5.1 = DNS-Redirect + Live-Torch für Low-Trust-Geräte/Airfryer hängt dran) → TP6 (QoS/CAKE). TP7 (mDNS) ✅ 2026-07-02 (inkl. HA/vlan20), TP3 (WLAN/CAPsMAN) ✅ 2026-06-18, TP3.1 (ap2-VLAN-Trunk) ✅ 2026-07-01, TP3.2 (P750W/Discovery) ✅ 2026-07-02, Sonos-Migration ✅ 2026-07-02 (alle 10 auf VLAN 40). ⏳ TP3.3 (WLAN-Coverage-Kur) offen — Fortsetzung neue Session (docs/wifi-p750w-coverage-and-map.md).
5. TP10 (VPN) ✅ Kern durch (2026-06-27) + Edge-Cutover (2026-07-01) → DURCH. Offen nur: DDNS-Auto-Updater.
6. Nachgelagert/Research-getrieben: TP8 (Access), TP9 (HA), TP11 (Monitoring + CF-Tunnel-Track-B/C), TP12 (IPv6), TP13 (Spaß).
7. Foundation (2026-07-14): TP15 (MikroTik-Switching / Omada-WLAN, 2× CRS326 bestellt) ∥ TP20 (Platform-Postgres, single-site replication-ready) → TP21 (Nautobot Golden Config) ∥ TP20.1 (Vaultwarden→PG + 2-Site-HA). TP20 hängt an TP18 ① (Garage-Bucket für pgBackRest).