docs/06-pve-test-wifi-network.md

@@ -181,31 +181,44 @@ a real outage**: SSH (`ssh root@pve-test.sweet.home`) → web UI via `curl
 only then worry about `ping` specifically, and check
 `/etc/pve/firewall/cluster.fw` before blaming the network.
 
-## Real limitation: other wifi clients on the same AP may not reach pve-test at all
+## Confirmed limitation: no wireless client on the same AP can reach pve-test
 
-If a client device is connected to the **same wifi network** pve-test
-uses (`nbn-fttp-net-5G`) and the router has **AP/client isolation**
-enabled for that SSID (common default on many consumer routers, and easy
-to have on without realizing it), that device cannot reach pve-test —
-not intermittently, not slowly, just never. Client isolation blocks
-Layer 2 traffic between wireless clients on the same AP; wired devices
-(anything behind the router's LAN ports, another node like `pve1`, VMs
-on either) are unaffected, which makes the symptom confusing: "every
-wired thing I test from reaches it fine, but my laptop on the same wifi
-can't" looks like a client-specific problem but is actually the router.
+**This is not an AP-isolation toggle** — tested and ruled out (router:
+TP-Link BE9300, AP Isolation confirmed unchecked). Two independent
+wireless devices (a laptop and a phone) on the same SSID pve-test uses
+(`nbn-fttp-net-5G`) were both completely unable to reach it — not
+intermittent, not slow, no ARP entry ever resolves (`arp -a` on Windows /
+`ip neigh` on Linux/Mac shows nothing at all, not a stale entry). Every
+wired device tested (this repo's own Claude session, `pve1`) reaches it
+fine, every time.
 
-Diagnostic signature: the affected device has **no ARP entry at all**
-for pve-test's IP (`arp -a` on Windows, `ip neigh` on Linux/Mac shows
-nothing, not a stale entry) — its ARP requests never get a reply because
-the AP drops them before they reach pve-test.
+Root cause: pve-test's wifi connection uses 4-address (WDS) framing to
+make bridging possible at all (see above) — that's what lets the AP
+forward frames from arbitrary MACs (VM traffic, the bridge's own
+identity) instead of only the wifi card's own hardware MAC. This
+router's firmware evidently handles wired↔pve-test forwarding for that
+4addr peer correctly, but doesn't correctly forward *wireless-client*
+broadcast/ARP traffic to it — an asymmetric gap in the AP's own 4addr
+handling, not a policy setting. Likely not fixable short of a firmware
+update from TP-Link (if one ever improves 4addr/WDS handling), possibly
+not fixable on this hardware at all.
 
-Fix is entirely router-side, nothing to change on pve-test: find
-"AP Isolation" / "Client Isolation" / "Wireless Isolation" in the
-router's wifi settings for that SSID and disable it (or exempt the
-specific devices that need to manage pve-test, if the router supports
-per-device exemptions). No pve-test or client-side networking change
-fixes this - don't waste time on ARP flushes, firewall rules, or bonding
-config for this specific symptom pattern.
+**Practical implication**: anything on `vmbr0` — pve-test itself, or any
+VM/CT created on it — is unreachable from a wireless client on this AP,
+full stop, for *any* protocol, not just ICMP. ARP resolution is a
+prerequisite for sending any IP packet at all (TCP included); since ARP
+itself never resolves for a wireless peer here, the web UI (8006) fails
+identically to ping, not just ping — confirmed live, not theoretical.
+This includes VMs on pve-test too, since they ride the same bridge/wifi
+uplink as the host. **Wired access is the only reliable path to
+pve-test and anything running on it** — including reaching a VM's
+console through the Proxmox web UI, which still requires the accessing
+device to reach pve-test's own IP on port 8006 first, so it inherits the
+same requirement.
+
+Don't waste time on ARP flushes, firewall rules, or bonding config for
+this specific symptom (no ARP entry from a wireless peer, wired fine) —
+none of those are the cause.
 
 ## Known limitation history