# Wireless > Authenticated Ruckus Unleashed cluster, radio, and WLAN policy evidence with explicit remaining failover and end-to-end verification gaps. Status: stale · Kind: snapshot · Last verified: 2026-07-12 · Date: 2026-07-12 > **Status:** stale > **Last fully verified:** 2026-07-12 > **Current evidence boundary:** an authenticated read-only controller capture on > 2026-07-20 supports the cluster, firmware, radio, WLAN, VLAN, security, and > controller-side client-policy details below. Management takeover, explicit > 802.11v state, and end-to-end QoS preservation remain unverified, so this page > stays stale. ## Purpose Wireless extends the wired VLAN fabric rather than creating separate security policy. Access points bridge clients into defined trust zones; routing and inter-zone authorization remain at the edge router. --- ## Current Cluster and Radio Evidence The 2026-07-20 authenticated capture confirms: - a two-AP Ruckus Unleashed cluster with one R750 and one R650 - the R750 currently providing the controller role - one shared `200.19.7.11 build 283` firmware version across both APs - enabled dual-band 802.11ax radios on both APs - 20 MHz 2.4 GHz operation on channels 1 and 11, constrained to the non-overlapping 1/6/11 pool - 80 MHz 5 GHz operation on channels 36 and 149, with configured channel pools limited to non-DFS ranges - controller-default transmit power on both 2.4 GHz radios and explicit, per-AP transmit-power values on both 5 GHz radios Both AP records report mesh capability enabled, but the capture does not expose an explicit management-failover setting or test actual takeover. Failover behavior therefore remains an unresolved operational claim rather than a current fact. --- ## Current Verification Status The scheduled wireless health producer is current, and the authenticated capture covers the controller-side configuration published below. The remaining gaps require evidence outside that capture rather than guesses from nearby settings. Because management takeover, explicit 802.11v state, and end-to-end QoS behavior remain unverified, this page stays `stale` and its `last_verified` date is unchanged. --- ## Current WLAN and VLAN Policy The controller exposes two locally bridged wireless classes aligned with the wired trust model: - The trusted class uses the native/untagged trusted path, 5 GHz, WPA3 with AES, required protected management frames, and no wireless client isolation. - The IoT class uses the tagged IoT path, 2.4 GHz, WPA2 with AES, protected management frames disabled for compatibility, and per-AP client isolation. Both use personal authentication without publishing passphrases. Neither is a guest WLAN, and captive-portal authentication is disabled. No camera WLAN is present. The controller mappings agree with the documented AP uplinks: trusted traffic is native and IoT traffic is tagged before the switching fabric carries it to the router-owned security boundary. --- ## Current Roaming and Client Policy Both classes advertise 802.11k neighbor reports and enable controller-assisted smart roaming. Their remaining policy intentionally differs: - The trusted class enables 802.11r fast transition. - The IoT class disables fast transition for compatibility. - Client balancing and band balancing are disabled on both classes; each class is bound to its intended band instead of relying on cross-band steering. - Per-WLAN throughput presets are disabled. The classes retain distinct queue priorities, but the controller capture alone does not prove end-to-end DSCP preservation through the wired and WAN paths. The capture does not expose an unambiguous 802.11v field. Smart-roaming and neighbor-report settings are not treated as substitutes for that missing protocol evidence. --- ## Remaining Evidence Before Active Status - observe or attend management takeover between the two APs - capture an explicit 802.11v setting or establish that the firmware does not expose one - verify QoS/DSCP preservation end to end rather than inferring it from controller queue settings Cluster membership, models, current controller role, firmware, radio policy, WLAN/VLAN mapping, authentication, protected management frames, isolation, guest posture, 802.11k, 802.11r, smart roaming, balancing, and controller-side QoS are covered by the current evidence. --- ## Architectural Invariants Even while the snapshot is stale, these design boundaries remain intentional: - APs and ordinary switches provide Layer 2 transport. - VLAN assignment determines the client's trust zone. - The router owns inter-zone firewall and routing policy. - Wireless policy must not create an undocumented path around wired trust boundaries. - RF or client-policy changes require separate evidence and rollback planning. --- ## Related Documentation - [Switching & VLAN Fabric](/homelab/network/switching-and-vlan-fabric) — AP uplink and VLAN transport boundaries - [Edge & Traffic Policy](/homelab/network/edge-and-traffic-policy) — Routing and trust-zone enforcement - [Network Monitoring Intent](/homelab/network/monitoring-and-observability) — Freshness and evidence boundaries