1 changed files with 35 additions and 22 deletions
@@ -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
+**This is not an AP-isolation toggle** — tested and ruled out (router:
-uses (`nbn-fttp-net-5G`) and the router has **AP/client isolation**
+TP-Link BE9300, AP Isolation confirmed unchecked). Two independent
-enabled for that SSID (common default on many consumer routers, and easy
+wireless devices (a laptop and a phone) on the same SSID pve-test uses
-to have on without realizing it), that device cannot reach pve-test —
+(`nbn-fttp-net-5G`) were both completely unable to reach it — not
-not intermittently, not slowly, just never. Client isolation blocks
+intermittent, not slow, no ARP entry ever resolves (`arp -a` on Windows /
-Layer 2 traffic between wireless clients on the same AP; wired devices
+`ip neigh` on Linux/Mac shows nothing at all, not a stale entry). Every
-(anything behind the router's LAN ports, another node like `pve1`, VMs
+wired device tested (this repo's own Claude session, `pve1`) reaches it
-on either) are unaffected, which makes the symptom confusing: "every
+fine, every time.
 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**
+Root cause: pve-test's wifi connection uses 4-address (WDS) framing to
-for pve-test's IP (`arp -a` on Windows, `ip neigh` on Linux/Mac shows
+make bridging possible at all (see above) — that's what lets the AP
-nothing, not a stale entry) — its ARP requests never get a reply because
+forward frames from arbitrary MACs (VM traffic, the bridge's own
-the AP drops them before they reach pve-test.
+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
+**Practical implication**: anything on `vmbr0` — pve-test itself, or any
-"AP Isolation" / "Client Isolation" / "Wireless Isolation" in the
+VM/CT created on it — is unreachable from a wireless client on this AP,
-router's wifi settings for that SSID and disable it (or exempt the
+full stop, for *any* protocol, not just ICMP. ARP resolution is a
-specific devices that need to manage pve-test, if the router supports
+prerequisite for sending any IP packet at all (TCP included); since ARP
-per-device exemptions). No pve-test or client-side networking change
+itself never resolves for a wireless peer here, the web UI (8006) fails
-fixes this - don't waste time on ARP flushes, firewall rules, or bonding
+identically to ping, not just ping — confirmed live, not theoretical.
-config for this specific symptom pattern.
+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