From f8ffc0d9ea924a3eb1bee9a01461ef247ebee013 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Mon, 24 Aug 2026 07:34:04 +0200 Subject: [PATCH] TP16 abgeschlossen: vier tote Tunnel geloescht; TP25 Kanalplan fuer AP3 - Vier Alt-Tunnel (openclaw/coolify/johnny2/TeilzeitCharlie) per CF-API geloescht, User-Entscheid. Gegenprobe: 5 Tunnel, bf-* je 2 Connectoren. Letzte VLAN1-Origins damit auch aus der CF-Config weg (Rest von TP19) - TP25: Kanalplan fuer den dritten AP gerechnet, DFS genehmigt. ETSI-Budget als Tabelle (Band A/B/C, 40-MHz-Bloecke duerfen keine Bandgrenze queren). Empfehlung: neuer cAP ax auf 5180/Ce non-DFS, ap1/ap2 nach Band B (5260/5300), 5220/Ce als Ausweichspur frei. Band B statt C wegen CAC 60s statt 600s und gleichem 23-dBm-Deckel - Zwei Fallen benannt: hart gepinnte Frequenz macht DFS zum SPOF (Channel-Objekt braucht eine Liste), und die erreichte tx-power in Band B messen BEVOR umgezogen wird -- das ist Fund B nochmal - Platzierung: Messung widerspricht dem Aufstellen an bisheriger Stelle (17/21 Abschnitte haben 0% Verlust). Vorschlag: cAP ax an den guten Platz, verdraengter hAP in den Drei-Zimmer-Schatten Co-Authored-By: Claude Opus 5 --- docs/cf-tunnel-mapping.md | 18 +++++++++ docs/teilprojekte.md | 78 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 95 insertions(+), 1 deletion(-) diff --git a/docs/cf-tunnel-mapping.md b/docs/cf-tunnel-mapping.md index 9f5e4ca..b466c2f 100644 --- a/docs/cf-tunnel-mapping.md +++ b/docs/cf-tunnel-mapping.md @@ -401,3 +401,21 @@ Störungsbehebung.** Weiterhin user-gated (Löschen ist nicht umkehrbar). ℹ️ **Nicht Teil des BF-HA-Designs** (und daher kein Defekt, obwohl sie 1 Connector haben): `fm.emsenhuber.net` (Standort FM) und `terpene-db` (eigenes Projekt). + +### ✅ Nachtrag 2026-08-24 — die vier toten Tunnel sind gelöscht +User-Entscheid „alle vier löschen". Über die CF-API entfernt, je `success: true`: +`openclaw` (`7a8f7b53`), `coolify` (`4f54ad8a`), `johnny2` (`acc73eb5`), `TeilzeitCharlie` (`6c784c98`). + +**Gegenprobe direkt danach — 5 Tunnel verbleiben:** + +| Tunnel | Status | Connectoren | +|---|---|---| +| `bf-mm` | healthy | **2** | +| `bf-nas` | healthy | **2** | +| `bf-pve` | healthy | **2** | +| `fm.emsenhuber.net` | healthy | 1 *(Standort FM, kein BF-HA-Ziel)* | +| `terpene-db` | healthy | 1 *(eigenes Projekt)* | + +Nebenwirkung, die zu **TP19** gehört: mit `openclaw` und `coolify` sind die letzten **VLAN1-Origins** +(`10.40.41.147`, `.148`, `.139`, `.133`) aus der Cloudflare-Konfiguration verschwunden. `.41.133` war +eines der „unidentifizierten VLAN1-Geräte" aus TP19 B1.2 und ist damit endgültig abgeräumt. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 00913e3..d63fa07 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -295,7 +295,12 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na - **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. -- 🧹 **Nebenbefund beim selben Sweep — 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) +- ✅ **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 @@ -870,6 +875,77 @@ begründet** — er kaufte Redundanz, keine Abdeckung. Das ist eine andere Frage 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