Wireless

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 — AP uplink and VLAN transport boundaries
• Edge & Traffic Policy — Routing and trust-zone enforcement
• Network Monitoring Intent — Freshness and evidence boundaries