Files
bf-infra/docs/wifi-p750w-coverage-and-map.md

117 lines
6.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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.