diff --git a/docs/06-pve-test-wifi-network.md b/docs/06-pve-test-wifi-network.md
index f77900f..bbf990d 100644
--- a/docs/06-pve-test-wifi-network.md
+++ b/docs/06-pve-test-wifi-network.md
@@ -181,6 +181,32 @@ 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
+
+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.
+
+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.
+
+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.
+
 ## Known limitation history
 
 `nic0` (the bond's backup slave) initially had no cable physically