From 1188adfa9cd3d7cbb16322788146edf7519f3279 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Fri, 3 Jul 2026 06:42:55 +0200 Subject: [PATCH] =?UTF-8?q?docs=20=F0=9F=93=84=20wifi:=20P750W-Fix,=20Cove?= =?UTF-8?q?rage-Stand=20&=20Interface-Map=20(Zwischendoku)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - P750W (VLAN30) gelöst: DHCP-client-id-Fix, geordneter ap1-Access-List-Pin (dozende Legacy-Clients nur am co-located-GW ap1 erreichbar), mDNS-vlan30-Discovery - Coverage an Kanten/Terrasse grenzwertig (−76..−89 dBm, 4-Radio-Ping-Pong); TX bereits am AT-Maximum; Steering (neighbor-group bf-main) gesetzt; echter Fix = Platzierung (Dead-Spot-Map offen) - Interface-Map als SSoT (ap1 statisch w2-/w5-, ap2 dynamische CAP-Slaves nicht praktikabel umbenennbar); Session-Änderungen + Journal-IDs + Backups Co-Authored-By: Claude Opus 4.8 --- docs/wifi-p750w-coverage-and-map.md | 116 ++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 docs/wifi-p750w-coverage-and-map.md diff --git a/docs/wifi-p750w-coverage-and-map.md b/docs/wifi-p750w-coverage-and-map.md new file mode 100644 index 0000000..05d4bad --- /dev/null +++ b/docs/wifi-p750w-coverage-and-map.md @@ -0,0 +1,116 @@ +# WLAN: P750W-Fix, Coverage-Stand & Interface-Map (Zwischendoku 2026-07-02) + +Arbeitsstand-Doku für künftige Sessions. Kanonischer Projekt-Tracker bleibt `docs/teilprojekte.md`. + +--- + +## 1. Interface-Map (SSoT — „was ist was") + +### ap1 (CAPsMAN-Manager + AP, 10.40.41.1, RouterOS 7.23.1) +Lokale Master-Radios: +- `wifi1` = **5 GHz**, ch36/5180, 20/40/80 MHz — SSID `dirtyvader-main`, VLAN10 +- `wifi2` = **2,4 GHz**, ch1/2412, 20 MHz — SSID `dirtyvader-main`, VLAN10 + +Lokale statische Slave-VAPs (stabile Handnamen; Prefix = Band-Radio): +| Name | Radio | Band | SSID | VLAN | +|---|---|---|---|---| +| `w2-iot` | wifi2 | 2,4 | dirtyvader-iot | 30 | +| `w2-media` | wifi2 | 2,4 | dirtyvader-media | 40 | +| `w2-untrusted` | wifi2 | 2,4 | dirtyvader-untrusted | 50 | +| `w2-guest` | wifi2 | 2,4 | dirtyvader-guest | 90 | +| `w5-media` | wifi1 | 5 | dirtyvader-media | 40 | +| `w5-untrusted` | wifi1 | 5 | dirtyvader-untrusted | 50 | +| `w5-guest` | wifi1 | 5 | dirtyvader-guest | 90 | + +⚠️ **Auf ap1 fehlt `dirtyvader-infra` (VLAN20)** — kein lokaler w2-/w5-infra-Slave angelegt. +INFRA sendet aktuell **nur auf ap2**. IOT ist 2,4-only (kein w5-iot, gewollt). → offener Punkt. + +CAPsMAN-Repräsentationen von ap2 (dynamisch, auf dem Manager sichtbar): +`cap-wifi1` = ap2-2,4G-Master · `cap-wifi2` = ap2-5G-Master · `cap-wifiN-virtualN` = ap2-Slaves. + +### ap2 (CAP, 10.40.41.2) +Master: `wifi1` = **5 GHz** ch149/5745 · `wifi2` = **2,4 GHz** ch11/2462 (beide `dirtyvader-main`). +Dynamische Slaves (Auto-Nummern, **ändern sich bei jedem Re-Provision**): +| Name (Stand 2026-07-02) | Radio | Band | SSID | +|---|---|---|---| +| wifi13 | wifi1 | 5 | untrusted | +| wifi14 | wifi1 | 5 | guest | +| wifi15 | wifi1 | 5 | infra | +| wifi22 | wifi1 | 5 | media | +| wifi16 | wifi2 | 2,4 | iot | +| wifi18 | wifi2 | 2,4 | untrusted | +| wifi19 | wifi2 | 2,4 | guest | +| wifi20 | wifi2 | 2,4 | infra | +| wifi21 | wifi2 | 2,4 | media | + +### Nomenklatur — Realität & Entscheidung +- ap1-Slaves (`w2-*`/`w5-*`) sind **stabil und lesbar** (w2=2,4G, w5=5G, Suffix=SSID). +- **ap2-Slaves sind dynamisch** und tragen CAPsMAN-Auto-Nummern (wifi13–22). Sauberes + Umbenennen ist **nicht zuverlässig möglich**: `name-format` greift nur eingeschränkt (v. a. + remote), Indizes laufen bei Re-Provisions hoch (heute live: wifi73→wifi80→wifi13–22), + und `name-format` kann die SSID nicht in den Namen kodieren (Forum-bestätigt). +- **Deshalb ist der „Durchblick"-Hebel diese Map + die eingebauten Interface-Kommentare** + (`/interface/wifi print detail` zeigt je VAP `;;; mode: AP, SSID: dirtyvader-X`), NICHT Umbenennen. +- Kanalplan überlappungsfrei: ap1 ch1/ch36, ap2 ch11/ch149. +- TX-Power 18 dBm (5G) / 15 dBm (2,4G) = **AT-Regulatorik-Maximum** (hAP ax² Antennen ~4/4,5 dBi, + EIRP-Deckel). „Lauter drehen" ist faktisch ausgereizt. + +--- + +## 2. SSID-/Security-Überblick +| SSID | VLAN | Auth | FT | Bänder | multicast-enhance | +|---|---|---|---|---|---| +| dirtyvader-main | 10 | wpa3 | **yes** (+over-ds) | 5G+2,4G | – | +| dirtyvader-iot | 30 | wpa2/3 | no | 2,4G | **enabled** | +| dirtyvader-media | 40 | wpa2/3 | no (Sonos-Bug) | 5G+2,4G | **enabled** | +| dirtyvader-untrusted | 50 | wpa2/3 | no | 5G+2,4G | – | +| dirtyvader-guest | 90 | wpa2/3 | **yes** (seit 2026-07-02) | 5G+2,4G | – | +| dirtyvader-infra | 20 | wpa2/3 | no | 5G+2,4G | – (nur ap2!) | + +Steering: Profil `st-main` / `neighbor-group=bf-main` auf beiden Main-Configs (seit 2026-07-02). + +--- + +## 3. Brother P750W (VLAN30) — gelöst +Label-Drucker, **mobil/batteriebetrieben**, MAC `4C:EB:BD:E3:25:F2`, IP `10.40.30.5`. +- **DHCP:** statische Lease, `client-id` entfernt → matcht über MAC. +- **An ap1 gepinnt** (geordnete wifi-access-list): `0 accept interface=w2-iot` → `1 reject` (ohne + Interface = jede ap2-VAP, **überlebt Re-Provision**). Grund: dozende Legacy-Clients sind nur am + AP mit co-located L3-Gateway (ap1) per ARP erreichbar; CAP ap2 puffert Broadcast-ARP unzuverlässig. +- **mDNS-Discovery:** `vlan30` in `mdns-repeat-ifaces` + 5353-Input-Regel → in MAIN-Netzwerkumgebung auffindbar. +- **Webinterface:** `http://10.40.30.5/general/information.html?kind=item` (DirectPrint-Pfad = 404). +- **Status:** Druck + Selbsttest OK. +- Merkregel: **DHCP-geht-aber-Ping-nicht = ARP/Power-Save, NICHT Routing/L2/MTU/Switch.** + +--- + +## 4. Coverage — offener Kernpunkt +- **Kanten/Terrasse grenzwertig:** Clients (iPhone, iPad) landen bei −76…−89 dBn und springen + zwischen allen 4 Radios („0–1 Striche + Abriss"). Terrasse auch mittags schlecht. +- **NICHT durch Config-Änderungen verursacht:** ap1 kein Reboot, RF-Konfig unverändert. +- Gegenmaßnahme bisher: **Steering** (Neighbor-Group) — hilft Entscheidung, macht Signal nicht stärker. +- **Echter Fix = Platzierung** (offen, Tageslicht): Dead-Spot-Kartierung → ap2 umstellen / 3. AP / + Outdoor-Unit; danach Nachbar-Kanal-Scan gegen Abend-Congestion. +- ap1-only ist damit **vom Tisch** (echte Funklöcher) — beide APs nötig, aber besser platziert. + +--- + +## 5. Änderungen dieser Session (2026-07-02) — Rollback-Journals +- INFRA-SSID angelegt (cfg-infra/sec-infra/dp-infra + Provisioning; ap2 bridge-vlan 20). +- P750W DHCP `client-id` entfernt (`NTG225AmxXM9yqgQDmlG2`). +- Access-List-Pin ap1: accept `FW6EBrj_y_i-HvYMe1Iw6`, reject `O72oAlXHtOxTpSXAdk4C9`. +- multicast-enhance iot `YZuWHB82fTB5VDIsTx-t3`, media `DPmI1fR65iTVi7Rl6Hqjn`. +- Guest FT=yes `yiKTRqMwDHaddXc1yrSNb`. +- mDNS: dns `-AKm4xgZiyvBZTAnKbhjt`, firewall `u_XvO_9hFtvdwqmzF2C9G`. +- Steering: add `AX6eoLCr4SGt19TSOoyMM`, cfg-5g `uqVqqvGocheBtKU2Hs_vT`, cfg-2g `7H5j6jIMP5D0uU16CpNTC`. +- **Backups (auf den Geräten):** `bf-ap1-pre-nomen-20260702.backup`/`.rsc`, + `bf-ap2-pre-nomen-20260702.backup`/`.rsc`. + +--- + +## 6. Offene Punkte / Next +1. **Coverage-Remediation** (Tageslicht): Dead-Spot-Map → Platzierung/3. AP; Nachbar-Kanal-Scan. +2. **INFRA auf ap1** ergänzen (fehlender lokaler Slave) — falls INFRA-Abdeckung an ap1-Seite nötig. +3. **Roaming-Feintuning** nach Kartierung (Steering-Schwellen 802.11v, ggf. Band-Overlap reduzieren). +4. Nomenklatur: **dokumentiert** (Umbenennen dynamischer CAP-Slaves nicht praktikabel — Map = Tool). +5. Finale Politur/Verweis in `docs/teilprojekte.md` + `CLAUDE.md`-Gotcha, wenn Coverage steht.