docs 📄 P750W/WLAN-Coverage in CLAUDE.md, teilprojekte, inventory nachgezogen

- CLAUDE.md: Gotcha CAP-Reachability (dozende Legacy-Clients nur auf ap1) +
  Merkregel DHCP-geht-Ping-nicht=ARP/PowerSave + Coverage/TX/Steering-Stand
- teilprojekte.md: TP3.2 (P750W gelöst, Coverage-Kur offen, Nomenklatur-Realität)
- inventory/bf.md: P750W Web-UI-Pfad + ap1-Pin-Hinweis

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

CLAUDE.md

@@ -68,3 +68,4 @@ GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`.
 - **TP4 ✅: ap1 ist L3-Router.** Bridge mit vlan-filtering=yes; VLAN1 untagged (Mgmt/Transition); vlan10-99 Subinterfaces mit DHCP+DNS. DNS: 13 statische A-Records bf.lan, **Upstream seit 2026-06-16 = DoH Cloudflare Gateway** (servers=1.1.1.1 Bootstrap). Omada-PVID-Fix (→ .10/.20-Subnetze) ist nächster Schritt.
 - **✅✅ Edge-Cutover vollzogen (2026-07-01): FritzBox komplett ausgebaut, Arris-Kabelmodem im Bridge-Mode.** Liwest hat die FB6660 dauerhaft gegen ein Arris-Kabelmodem getauscht (physisch weg, kein Zurück). WAN läuft über den Core-Switch (Arris→sw1 gi16 Access VLAN100→gi15 Trunk→ap1 ether2→`vlan100` auf bridge), NICHT über ether1. ap1 zieht öffentliche Liwest-IP direkt → Double-NAT weg, ap1 = Public-Edge. Vorarbeit dazu: TP10 (beide VPN FM/DW von FB auf ap1-WG-Hub migriert, 2026-06-27) hat den Bridge-Mode entblockt. Telefonie war auf der FB und wird **nicht weitergeführt** (User-Bestätigung 2026-07-02). Details/Runbooks: `routeros/wan-cutover-runbook.md`.
 - **ap1 RouterOS-Scripting (device-mode=home):** **scheduler + fetch blockiert** (`not allowed by device-mode`) → keine Scheduler in Scripts, Autonomie via Loop-Script. **`[/ping]` gibt nil in 7.23**, ICMP geblockt → Reachability via `:resolve` (server=1.1.1.1 = Routing-Test, ohne server = DoH). MikroMCP-Tools können droppen → Fallback REST `http://10.40.41.1/rest` (Creds = ROUTER_AP1 in `~/.claude.json`).
+- **WLAN dozende Legacy-Clients nur auf ap1 erreichbar, NICHT via CAP ap2 (2026-07-02, P750W-Fall):** L3-GW liegt auf ap1 → ARP-Broadcast an schlafenden Client wird nur am co-located AP zuverlässig zugestellt; Remote-CAP ap2 puffert Broadcast-ARP unzuverlässig. Fix = geordneter wifi-access-list-Pin auf ap1 (`0 accept interface=w2-iot` → `1 reject` ohne Interface = überlebt ap2-Re-Provision). **Merkregel: DHCP-geht-aber-Ping-nicht = ARP/Power-Save, NICHT Routing/L2/MTU/Switch.** Coverage-Kanten/Terrasse grenzwertig (−76..−89 dBm, 4-Radio-Ping-Pong); TX schon am AT-Max (18/15 dBm, kein Hebel); Steering `neighbor-group=bf-main` gesetzt; echter Fix = Platzierung (offen, Tageslicht). SSoT `docs/wifi-p750w-coverage-and-map.md`.

docs/teilprojekte.md

@@ -109,6 +109,19 @@ Kontrolle: MikroMCP (MikroTik) live · ALLNET = Klickanleitungen · Omada → Co
   sein (nicht `defconf`/`10.40.41.x`). Falls kein DHCP: Omada-Port-2-Trunk (tagged 10/30/40/50/90) prüfen.
 - Abh.: TP3 ✅, TP4 ✅ (Bridge-VLAN-Muster gespiegelt). Config ap2-lokal (nicht CAPsMAN-verwaltet).
 
+### TP3.2 — WLAN Coverage / P750W-Discovery ▸ ⏳ teil-erledigt (2026-07-02) — `docs/wifi-p750w-coverage-and-map.md`
+- ✅ **Brother P750W (VLAN30) gelöst:** DHCP-`client-id`-Fix (matcht über MAC → feste `10.40.30.5`); **an ap1 gepinnt**
+  (geordnete wifi-access-list `accept w2-iot` → blanket `reject`, überlebt ap2-Re-Provision) — dozende Legacy-Clients
+  nur am co-located-GW ap1 per ARP erreichbar, CAP ap2 nicht; mDNS `vlan30` in `mdns-repeat-ifaces`+5353 → in MAIN
+  auffindbar. Druck+Selbsttest OK. Web-UI `http://10.40.30.5/general/information.html`.
+- ✅ **Nebenbei:** `multicast-enhance=enabled` (iot+media), Guest `ft=yes`, INFRA-SSID(20) angelegt (**nur ap2**),
+  Steering-Profil `st-main`/`neighbor-group=bf-main` auf beide Main-Configs.
+- ⏳ **Offen — Coverage-Kur (Tageslicht):** Kanten/Terrasse grenzwertig (−76..−89 dBm, 4-Radio-Ping-Pong; Terrasse
+  auch mittags). **TX schon am AT-Max** (18/15 dBm, kein Hebel). Echter Fix = **Platzierung** (Dead-Spot-Map →
+  ap2 umstellen / 3. AP / Outdoor); Nachbar-Kanal-Scan. **ap1-only vom Tisch** (echte Funklöcher). INFRA fehlt auf ap1.
+- **Nomenklatur:** dynamische ap2-CAP-Slaves (`wifi13–22`) nicht praktikabel umbenennbar (`name-format` unzuverlässig)
+  → Map dokumentiert statt umbenannt. Backups `bf-ap{1,2}-pre-nomen-20260702.backup`/`.rsc` auf den Geräten.
+
 ### TP4 — Router-Cutover (hAP#1 = Router + WAN-Edge) ▸ ✅ FERTIG (2026-07-01)
 - ✅ **Bridge VLAN-Filtering aktiviert** (`vlan-filtering=yes`); VLAN-Tabelle: VLAN1 untagged bridge+ether2, VLANs 10/20/30/40/50/90/99/100 tagged bridge+ether2.
 - ✅ **VLAN-Subinterfaces:** vlan10/20/30/40/50/90/99 auf bridge; je GW `.1` (10.40.10.1 … 10.40.99.1).

inventory/bf.md

@@ -16,7 +16,7 @@
 | ip | hostname | mac | pve_ct | server_ip | server_mac | note |
 |---|---|---|---|---|---|---|
 | 10.40.41.4 | MFC | 30:5:5c:78:86:20 |  |  |  |  |
-| 10.40.41.5 | P750W | 4C:EB:BD:E3:25:F2 |  |  |  | Brother PT-P750W Label-Drucker, **mobil/batteriebetrieben** (Standort variabel); aggressives WLAN-PowerSave → idle nicht ARP/ping-erreichbar (wifi-qcom-Limit), Druck weckt Gerät. Ziel-VLAN 30 (IoT), reserviert 10.40.30.5 |
+| 10.40.41.5 | P750W | 4C:EB:BD:E3:25:F2 |  |  |  | Brother PT-P750W Label-Drucker, **mobil/batteriebetrieben** (Standort variabel); aggressives WLAN-PowerSave → idle nicht ARP/ping-erreichbar (wifi-qcom-Limit), Druck weckt Gerät. Ziel-VLAN 30 (IoT), reserviert 10.40.30.5. Web-UI `http://10.40.30.5/general/information.html` (kein DirectPrint-Pfad); an ap1 gepinnt (wifi-access-list, anti-flap). Doku `docs/wifi-p750w-coverage-and-map.md` |
 | 10.40.41.6 | iHost | D0:27:03:C8:CB:36 |  |  |  |  |
 | 10.40.41.7 | odroid-m1 | 00:1E:06:51:31:C9 |  |  |  |  |
 | 10.40.41.8 | DTUBI-414392337823 | 54:F2:9F:12:51:F0 |  |  |  |  |