Environment
AP: Ruckus R720
Role: Master AP
Unleashed Firmware: 200.15.6.212.27
Guest SSID: Open authentication / No encryption
Guest Authentication: Enabled
Guest Access: Captive portal authentication
Additional AP: Ruckus R650, same firmware
Guest Authentication Methods:
Unique password for each guest
Single shared password among all guests
Issue Summary
We are experiencing a reproducible Guest Access authentication failure when "Allow users to reconnect without re-authentication for" (Grace Period) is enabled.
Initial Guest SSID authentication works normally. The client completes the Guest Access/captive portal process and receives network access.
However, after disconnecting from Wi-Fi and reconnecting within the configured Grace Period, the client briefly connects and then immediately disconnects.
The client does not reach DHCP and does not receive an IP address.
This is reproducible using a single AP, so it is not dependent on roaming.
Grace Period Testing
Tested Grace Period values:
10 minutes
1440 minutes
14400 minutes
43200 minutes
Grace Period Disabled
When "Allow users to reconnect without re-authentication" is disabled, the client reconnects normally and proceeds through the expected Guest Access authentication/captive portal process.
Grace Period Enabled
After the client has successfully authenticated, disconnects, and reconnects within the Grace Period:
Client associates/connects to the Guest SSID.
Client immediately disconnects.
No DHCP transaction occurs.
No IP address is assigned.
Client cannot reach the captive portal/network access stage.
If the Grace Period expires, the client can reconnect normally and authenticate again.
The same behavior occurs with both "Unique password per guest" and "Single shared password."
Client Testing
Reproduced with:
Apple iPhone
Android phone
Private/randomized MAC address
Device MAC address
The behavior is independent of client OS and MAC-address mode, making a client-specific issue unlikely.
Troubleshooting / Configuration Checks
The following were tested or eliminated as likely causes:
Restricted Subnet Access: Private IP pool entries removed during testing.
Walled Garden: Private IP pool and other relevant entries added; no change.
ACLs: No ACL applied to the AP port or relevant VLANs.
802.11r / Fast BSS Transition: Not enabled/not applicable for this Guest SSID.
802.11v: Not enabled/not shown as applicable.
802.11k: Enabled.
802.11d: Enabled.
Wireless Client Isolation: Disabled during testing; no change.
DHCP: Failure occurs before DHCP.
VLAN/ACL configuration: No change when modified/tested.
Roaming Eliminated
The issue can be reproduced using one AP only:
Connect phone to Guest SSID.
Complete Guest Access authentication.
Confirm connectivity.
Disconnect Wi-Fi.
Reconnect to the same SSID on the same AP within the Grace Period.
Client connects briefly and immediately disconnects.
Therefore, the issue does not require:
AP-to-AP roaming
Mobility between APs
Inter-AP guest-state synchronization
The issue was also reproduced between APs, but roaming is not required to trigger the failure.
R720 vs. R650 Testing
The issue is not specific to the R720.
It was reproduced on a Ruckus R650 running Unleashed 200.15.6.212.27:
R650 as part of an Unleashed deployment
R650 tested separately
The behavior remained the same.
When testing between APs in an Unleashed deployment, the issue also occurred regardless of which AP the client initially connected to or subsequently connected to.
802.11 Events
During the failed reconnect attempt, the following events are observed:
802.11 Disassociation — Reason Code 1: Unspecified
802.11 Deauthentication — Reason Code 5: Disassociation due to AP busy
802.11 Deauthentication — Reason Code 6: Received class 2 frame from non-auth STA
No DHCP transaction occurs after the failed reconnect.
Firmware Upgrade Path
The current R720-Master Unleashed cluster does not report 200.19 as an available/valid upgrade path.
Although newer Unleashed releases may exist for some Ruckus AP platforms, the R720-Master cluster reports no available upgrade to 200.19.
Therefore, upgrading to 200.19 is not currently an available remediation path for this deployment unless Ruckus confirms a supported upgrade path.
Expected Behavior
When a previously authenticated Guest Access client reconnects within the configured Grace Period, it should:
Be allowed to reconnect without re-authentication.
Remain associated.
Obtain an IP address through DHCP.
Receive normal network access according to the Guest Access configuration.
Actual Behavior
With Grace Period enabled:
Initial authentication → disconnect → reconnect within Grace Period → brief association → immediate disconnect → no DHCP/IP address.
With Grace Period disabled, or after the Grace Period expires, the client reconnects and proceeds through normal Guest Access authentication successfully.
Assessment
The failure appears specifically associated with:
Guest Access → Allow users to reconnect without re-authentication for (Grace Period)
Testing has largely eliminated:
Client OS/device-specific behavior
Private/randomized MAC addressing
Device MAC addressing
DHCP
VLAN ACLs
Walled Garden
Restricted Subnet Access
Wireless Client Isolation
AP-to-AP roaming
R720-specific hardware
A single defective AP
The failure occurs before DHCP and is reproducible across multiple client platforms and AP hardware.
Operational Impact
Due to this Guest Access Grace Period issue, we are currently using DPSK (Dynamic Pre-Shared Key) as an alternative guest-access method.
The Ruckus DPSK implementation provides a per-usage option, which is relevant to our guest-user requirements and differs from the DPSK implementation currently available in Ubiquiti UniFi.
Resolving the Guest Access Grace Period issue is therefore important for determining whether the Ruckus Guest Access workflow can meet our desired guest authentication model without requiring users to repeatedly authenticate.
Request to Ruckus / TAC
Can anyone confirm whether this is a known issue/software defect in Unleashed 200.15.6.212.27 involving:
Guest Access → Allow users to reconnect without re-authentication for (Grace Period)
Specifically:
Why is a previously authenticated Guest Access client being disconnected when reconnecting during the Grace Period instead of being permitted to reconnect without authentication?
Is this a known issue in 200.15.6.212.27?
Is there a firmware release containing a fix that is actually supported as an upgrade path for an Unleashed cluster with an R720 as Master?
Is any additional configuration required for Guest Access Grace Period functionality?
What debug commands, support logs, or packet captures are required by Ruckus TAC?
Are 802.11 Reason Codes 1, 5, and 6 expected consequences of a Guest Access Grace Period failure, or do they indicate a separate AP/client state-machine issue?
Are there known limitations with Grace Period and either:
Unique password for each guest
Single shared password among all guests?
Minimal Reproduction
Configuration:
Ruckus R720
Unleashed 200.15.6.212.27
Guest SSID: Open / No Encryption
Guest Authentication: Enabled
Captive Portal
Authentication method: Unique password per guest OR Single shared password
Grace Period: Enabled
Steps:
Connect client to Guest SSID.
Complete Guest Access authentication.
Confirm connectivity.
Disconnect Wi-Fi.
Reconnect within the configured Grace Period.
Observe brief connection followed by immediate disconnect.
Confirm that no DHCP address is obtained.
Reproduced with iPhone and Android, using both private/randomized MAC and device MAC, and on both R720 and R650 hardware.
