A network can have coverage everywhere and still feel unpredictable if devices do not move between access points properly. A phone or computer might stay connected to an access point after getting closer to another one, which can sometimes cause slower speeds or a weaker connection.

This issue seems obvious in bigger offices, schools, hotels, and other places where people are always moving around.

The way clients behave is also a factor. Different phones, computers, and smart devices make their decisions about when to switch access points, so just adding more access points does not always fix the problem.

Things like signal strength, where the access points are placed, how channels are set up, how much power they send out, and the settings for roaming can all impact the experience. It also seems helpful to check what the actual devices are doing, assuming every problem is caused by the access point.

For anyone who manages a wireless setup, I would like to know how you usually find out why a client stays connected to an access point that is far away.

Do you mainly check the strength of the client, the roaming events, the access point settings, or the device itself?

Any assistance would be so much appreacited.

Thanks

To that end, I have already downloaded the unleased version R850_200.19.7.112.238.bl7 file.

Article number 000005720 https://support.ruckuswireless.com/articles/000005720 lists the procedure for just this, but it was last updated in March 2021.

• Is this still valid?
• The current device that I am looking to purchase was purchased in Aug 2025, and I do not know the current firmware on it.
• Does it matter what the current non unleashed firmware version is on it?

This is the first time I am dealing with Ruckus products, and I want to make sure the educated / experienced community here says that I am ok to proceed with the purchase on these grounds.

Thank you.

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.

I am looking to purchase an R850 as a private sale. The seller states that this is brand new in box, and it does appear to be. I want to walk through what I did as testing before I walked away because I was not able to reach the management page. The product code was a 901 and not a 9U1, so at least at factory it is NOT an unleashed firmware (although I will eventually convert to unleashed)

• I used a PoE+ switch port (my mistake, I thought this would be sufficient)
• The switch I took for testing was a basic PoE+ switch.
• I powered the 850, it came up, and it with a Connect.me wlan
• It asked for a security key which was the serial number, and it worked
• I connected to it successfully from my laptop, but never got an IP, and thus was never able to browse to either 192.168.0.1 or to unleashed.ruckuswireless.com
• when I tried to use the app, my phone was never able to connect to the connect.me network

My basic troubleshooting has led me to this:

• Since I was on lower power, the 1Gig port never activated
• However, I was under the impression that Mode 0 should have been enables as the witch port was supplying max 30W per switch port
• Since this test network was just the Layer 2 poe+ switch (802.3at), my laptop and the R850 (I don't know what mode), there was no dhcp server to hand out IP Addresses
• As a reult of this, IP addresses were never assigned, and there could be no browsing to the management address.

I should have posted this before I went to meet the seller, but such is life. I walked away thinking there was something wrong with the unit.

I do want this, but my PoE switch at home does not support this kind of power draw. I intend to get the Ruckus power injector.

My questions:

• Is my analysis above correct? or should I have been able to browse to a web site.
• If I just get the power injector and no dhcp server, will I be able to browse to 192.168.0.1 at least? or will I need a dhcp server for even that first step?
• Is the R850 on unleashed or controller based or stand alone mode?
• Should I lug a router / dhcp server next time I go to test during a sale?

Thank you for going through this and any recommendations are helpful

Also, does it matter if I connect powe+ switch port > 60W Power injector > R850 PoE port?

Since the outage, the RUCKUS Wi-Fi has severe intermittent packet loss. Internet sometimes works normally and then becomes extremely slow or stops responding.

Troubleshooting already completed:

• AT&T gateway connection is approximately 1 Gbps up/down.
• When connected directly to the AT&T gateway Wi-Fi, I get 0% packet loss.
• Through the RUCKUS Wi-Fi, a 100-packet test to 8.8.8.8 showed 59% packet loss.
• More importantly, a 100-packet test directly to my local AT&T gateway (192.168.1.254) showed 81% packet loss, so the problem appears to be inside the local RUCKUS network.
• Wi-Fi signal to the RUCKUS AP is strong (approximately -49 dBm).
• I have already power-cycled the ICX/APs.
• I also performed the ICX 7150-C12P physical recovery procedure by powering it off, holding Reset while reconnecting power, waiting for the LEDs to flash amber, and releasing Reset. The problem remains.
• The ICX switch powers up normally and the APs come online.

Switch: RUCKUS ICX 7150-C12P / ICX7150-C12P-2X1G

Hi

We moved into the new house and I am unable to use the Ruckus Wifi System in the house. I am new this system and donot know how to reset this wifi access point.

Thanks Raghu

Subject: R600 AP unable to successfully join Virtual SmartZone 6.1.2 - ZD to SZ migration

--- Environment ---

Controller: Virtual SmartZone Essentials 6.1.2.0.1071 (KVM/Proxmox)
Control Plane Software: 6.1.2.0.1018
AP Zone Firmware: 5.2.2.0.2122 (AP Patch scg-ap-5.2.2.0-2122.patch applied)
AP Zone Name: gclab-r600

Test AP: Ruckus R600

• MAC: F0:3E:90:32:8A:40
• Serial: 171603502066
• Current Firmware: 110.0.0.0.675 (SmartZone standalone)
• IP: 192.168.29.101/24
• Gateway: 192.168.29.1
• Management VLAN: 29

Network: AP is on VLAN 29 (192.168.29.0/24), vSZ control interface is on public subnet xxx.xxx.xxx.xxx/24. Inter-VLAN routing is confirmed working — AP can reach vSZ and vice versa.

Background: We are migrating from an end-of-life ZoneDirector 3050 managing 56 APs (50x R600, 3x R710, 3x T300). This is a test with a single R600 before production migration.

--- Attempt 1: ZD firmware AP connecting to vSZ (AP firmware 9.13.1.0.11) ---

1. AP was running ZoneDirector firmware 9.13.1.0.11
2. Set controller IP via SSH: set scg ip xxx.xxx.xxx.xxx
3. AP discovered the vSZ and was approved
4. vSZ rejected the AP with event code 2003: "ZD-AP [F0:3E:90:32:8A:40] / [171603502066] model [R600] is not being upgraded with Virtual SmartZone AP firmware because of ACL setting."
5. This repeated continuously despite creating an AP registration rule for subnet 192.168.29.0/24 pointing to the legacy-r600 zone

--- Attempt 2: After applying AP Patch and configuring lwapp2scg ---

1. Applied AP patch scg-ap-5.2.2.0-2122.patch to the vSZ
2. Configured lwapp2scg policy to accept via CLI
3. Added AP MAC to lwapp2scg ACL
4. AP discovered, was approved, and connected (event code 312)
5. vSZ initiated ZD AP migration — event code 2001: "ZD-AP upgrading with Virtual SmartZone AP firmware version - [5.2.2.0.2064]"
6. AP lost heartbeat (event code 314) and disconnected (event code 303)
7. AP appeared to enter a boot loop — ping from monitoring station showed AP dropping off every ~60 seconds and returning, suggesting repeated reboot cycles
8. AP never successfully reconnected after firmware push

--- Attempt 3: Pre-flashed SZ firmware on AP ---

1. Factory reset the AP
2. Manually flashed AP with SmartZone standalone firmware 110.0.0.0.675 via AP web UI
3. Confirmed firmware via SSH: get version shows 110.0.0.0.675
4. Configured AP: IP 192.168.29.101, gateway 192.168.29.1, management VLAN 29
5. Set lwapp2scg policy to accept-all on vSZ
6. Disabled ap-cert-check on vSZ
7. Created new zone gclab-r600 with AP firmware 5.2.2.0.2122
8. Set controller via SSH: set scg ip xxx.xxx.xxx.xxx
9. AP state cycles between DISC_REQ_STATE and JOIN_REQ_STATE
10. Reached CONN_GET_ADDR_STATE once briefly, then fell back to DISC_REQ_STATE
11. AP never fully connects or appears as managed in vSZ
12. No events appearing in vSZ event log for this attempt

--- vSZ Configuration ---

• Profile: Essentials (single NIC)
• lwapp2scg policy: accept-all
• AP certificate check: disabled
• L3 ACL: default-deny with permit rules for xxx.xxx.xxx.xxx/24 (DNS), 192.168.29.0/24 (AP network), plus DNS (port 53) and DHCP (port 67)
• AP auto-approval: disabled
• AP registration: rule removed (relying on lwapp2scg accept-all)

--- Questions ---

1. Is there a firmware compatibility issue between AP firmware 110.0.0.0.675 and vSZ 6.1.2? Should the AP be running a specific 5.2.2.x standalone image to match the zone firmware?
2. What is the correct procedure to migrate an R600 from ZoneDirector firmware to SmartZone on vSZ 6.1.2?
3. Are there specific ports beyond TCP 9100 that need to be open between the AP and vSZ for the join process to complete?
4. Is the R600 fully supported on vSZ Essentials 6.1.2, or only on specific earlier versions?

Any guidance on getting this R600 to successfully join the vSZ would be greatly appreciated. We need to validate R600 compatibility before proceeding with the full production migration of 56 APs.

We found a tricky issue.

We were using 2 x R770 as the 1st and 2nd preferred masters, not in dedicated mode.

About 35 member APs (R370) here. If we created more than one SSID (the default one), the R370 rebooted and looped in "Kernel panic".

Moreover, if we disconnect both R770s from the PoE switch, no R370 became as a new master of Unleashed, and the whole WIFI was dead.

WE are using 200.19.7.112.238.

If we reset all APs and only put 370 to online as master and member, everything is working well.

Does anyone know how we can fix this?

I have Purchase new Ruckus R550 and i try to configure 1st i configure that put poe cable from poe switch to Ap POE Port and from that Same Poe Switch to my laptop and i put one from ip from the same ip segment of the ruckus that is 192.168.0.122 and gateway 192.168.0.1 but it was not pinging 192.168.0.1 the default ip after that i was tryint to connect its Configure.Me. it was asking password and i checked behind there is no SSID-Password Mention it was frusted with this AP that no able to ping on lan and dont know the default ssid password can u please help me in that

I have tried to repower the switch and doing a reset with the reset button but the issue still persist.

Kindly assist. 

One of the frame's flows that affect the overall performance of the wireless network is the retransmission rate (a frame is retransmitted when the delivery was not acknowledged or it's reported as corrupted), excessive frame retransmission forces the client-AP to negotiate lower data rates for the communications, causing greater delay and higher airtime utilization.

How can I tell if the retransmission rate is high?

• From the AP support log. 

----------------------- Host/Target Tx Stats ----------------------
RKS stats magic: cafe0001
421200 MSDUs success(msdus_success)
4582766 MPDUs success(mpdus_success)
632 tx completions delivered(comp_delivered)
7828618 Tx HW queued(hw_queued)
7828618 Tx HW reaped(hw_reaped)
188 Tx MAC underrun(underrun)
1424910 Tx HW paused(hw_paused)
3290623 Tx seq posted(seq_posted)
740 Tx mu seq posted(mu_seq_posted)
72066 Tx seq failed(seq_failed_queueing)
1342284 MPDUs requed(mpdu_requed)
5925004 MPDUs tried(mpdu_tried)
2748 MPDUs sw_flush(mpdus_sw_flush)
19468 MPDUs truncated(mpdus_truncated)
1324450 MPDUs block ack_failed(mpdus_ack_failed)
568 MPDUs expired(mpdus_expired)
2654643 excess retries(tx_xretry) ------------------------> very high 'tx_xretry'
902025741 sched self trig(self_triggers)
116763 ampdu retry failed(sw_retry_failure)

Excessive retries can be directly related to PHY errors:

------------ Host/Tgt Rx Stats ------------
34066065 PPDUs Rx from HW(htt.ppdu_recvd)
31502324 MPDUs Rx OK(htt.mpdu_cnt_fcs_ok)
2602746 MPDUs Rx Err(htt.mpdu_cnt_fcs_err)
2696712 MPDUs dropped in FW ring(htt.fw_ring_mpdu_drop)
2599042 local mgmt Rx(pdev_local_buffer_stats.local_reaped)
63379830 Rx PHY errors(rx_phyerr) ---------------------------------> very high 'rx_phyerr'
34073621 Rx MPDU errors(rxdesc_err_att)
2599027 Rx MPDU FCS errors(rxdesc_err_fcs)

• From Wireshark.

Collect a packet capture on the specified wireless interface of the AP by selecting the AP and then click 'More'>Packet Capture.

In the Packet capure page, select the appropiae radio you want to monitor and the option 'save to file'. Click 'Start' to begin to capture and then 'Stop' to stop the capture. When the file is ready, the 'Download' option will appear for you to download the file.

Once you have got the pcap file, then you can look for the 'Retry' flag on the 802.11 information of the frame.

Right click and 'Apply as Filter>Selected to fiter out the all the retransmitted frames:

This is the wireshark filter for the retry flag in the frames.

wlan.fc.retry == 1

Check the total amount of packets in the file vs. the number of packets displayed and then you will have a meassure of the retransmission rate of the packets captured in the specific lapse. In our example, we have a 10% of retransmission rate.

We can see, for our example, the probe response from the AP was retrasmitted many times, which means  -most likely- the client never received it. This could have ended on a client unable to connect to the wireless network or maybe just connecting to the next available AP -no usually the closest one-.

What are the causes of high retransmission rates and how can I address them?

1. non-wifi interference. Identify the source of the interference and shut it down -if it's under your administration- or relocate the AP if the interference cannot be disabled.
2. wifi interference (co-channel or adjacent channel). Review the channel plan and choose a channel selection option that best services your enviroment.
3. hidden nodes. Reduce the cell size or relocate the AP.
4. poor signal to noise ratio. Identify the sources of the most noise signals and reduce/disable them -if it's under you administration- or relocate the AP if the interence cannot be reduced.
5. bad coverage configuration. Relocate the APs, add more APs or increase the cell size.

• Network connectivity issues
• Master AP election problems 
• Potential hardware failures
• Assessing controller connection status 

It's important to note that the presence and functionality of LED lights on a Ruckus AP can vary depending on the specific model and series. However, most Ruckus APs feature the following five LED indicators: PWR, CTL, AIR, 2.4G, and 5G.

PWR (Power Indicator):

Solid RED: Bootup in progress.

Flashing Green: AP firmware image booted. No routable IP received or assigned.

Solid Green: Routable IP address received.

CTL/DIR (Control/Direction Indicator):

Off: AP is a RUCKUS Unleashed member AP.

Slowly Flashing Green (every 2 sec): RUCKUS Unleashed Master AP discovery in progress.

Fast Flashing Green (twice a sec): Receiving configuration or image upgrade.

Solid Green: AP is the RUCKUS Unleashed Master.

AIR (Mesh indicator:)

Off: AP is operating in standalone or Root or non-Mesh AP        

Solid Green: AP is functioning as Mesh AP (MAP)        

Blinking Solid Green (2 Hz): AP is functioning as Mesh AP (MAP)        

Blinking Solid Green (0.5 Hz):         

2.4G (WLAN Service Indicator):

Off: The WLAN service is down.

Green: The WLAN is up, and at least one client is associated.

Amber: The WLAN is up, but no clients are associated.

5G (WLAN Service and Mesh Downlink Indicator):

Off: The WLAN service is down.

Green: The WLAN is up, and at least one client is associated. No downlink MAPs are connected.

Slow Flashing Green (one flash every two seconds): The WLAN is up, and at least one downlink MAP is connected. No clients are associated.

Fast Flashing Green (two flashes every second): The WLAN is up, at least one downlink MAP is connected, and at least one client is associated.

More info about the LEDs can be found here: https://docs.commscope.com/bundle/unleashed-200.10-troublshootingref/page/GUID-738984DA-2A47-4E71-A690-B6DF9023AA50.html

1. Client Connection Troubleshooting

Link as reference https://docs.commscope.com/bundle/unleashed-200.16-troublshootingref/page/GUID-5BBF52D0-939D-416F-B696-FABB12AC5EE9.html

This is a demonstration for the client troubleshooting.

Select Clients, and then click the Troubleshooting button.

Figure 1: Clients Tab

Here, we can enter the MAC address of the client device in the specified format to begin troubleshooting process. If the device is already connected to the network, simply click on it, and the troubleshooting process will begin automatically.

Figure 2: Troubleshooting button.

Identify the MAC Address: Obtain the MAC address of the client device you want to analyze. Ensure you have this information handy as it will be used to filter the capture.

Input the MAC address of the client device into the designated filter.

Click the Start button to begin the troubleshooting.

In this demonstration I will use the following Mac-address for one of my Wireless clients 62:b6:b1:eb:09:89

Figure 3: Start Troubleshooting Process

Once you click Start, no data will be displayed initially because the device has not yet connected to the network or attempted to connect to any of the AP's SSIDs.

Figure 4: Troubleshooting Process

In this example, I will attempt to connect my end client to the SSID of the Access Point and intentionally use an incorrect password.

Figure 5: Initial Packet Capture View

First, we will analyze what we are observing firsthand during this test. We can identify which Access Point the end device is connecting to, the band it is using (whether 2.4 GHz or 5 GHz), and in this case, it is 5 GHz on channel 157. Additionally, we can observe the environmental SNR and the timestamp of the events according to the Access Point's log.

Now we will analyze the packets exchanged between the end client and the Access Point.

Figure 6: Analysis of Packet Exchange Between Client and Access Point

The client device initiates the connection by sending authentication and association requests, which the AP responds to. During the 4-way handshake, each attempt fails repeatedly, suggesting there is an issue. After multiple failures, the AP deauthenticates the client, ending the connection attempt.

Figure 7: Final Analysis - Client Failed Handshake

When the Information button on the error is pressed, it often provides a suggested error code and status, which can also be copied for reference. In this example, the tool indicates an "invalid passphrase" error, accurately reflecting the intentional use of an incorrect password for testing purposes. This tool is highly effective for troubleshooting connectivity issues, as it provides insights into client behavior during the authentication process, in roaming scenarios, and across various other network situations.

2.    Capturing Remote Packets

Remote packet capture enables one or more APs to operate in packet sniffer mode, allowing them to capture wireless packets on the network. These packets can either be saved locally on the device or streamed in real time to a packet analysis tool, such as Wireshark, for detailed inspection and troubleshooting. This feature is valuable for diagnosing connectivity issues and monitoring network performance by analyzing the captured packet data.

Link as reference https://docs.commscope.com/bundle/unleashed-200.16-onlinehelp/page/GUID-FE747C7C-8F63-409B-A423-63F898CA8331.html

Go to Admin & Services > Administration > Diagnostics > Packet Capture.

Figure 8: Packet capture tab

In this section, we will find the Access Points in our network, along with their model, device name, and corresponding IP address.

To troubleshoot the client connectivity issue, select the desired APs, and then choose Add to Capture. This action will move the APs to the Capture APs table.

Figure 9: Selecting the Access Point for the Packet Capture

For Radio, select either 2.4 GHz or 5 GHz/6 GHz. In this case, since we are working with a 5 GHz connection, select the 5 GHz option.

You can Select Local Mode or Streaming Mode as the capture mode:

+To capture a limited snapshot on each AP, select Local Mode.
+To stream the captured packets directly to Wireshark for real-time analysis, select Streaming Mode.

In this example we are going to select Local Mode.

In this example, since the MAC address of the problematic device is known, enter it to filter the capture data specifically for that client. Click Start to begin capturing packets. At this stage, reproduce the issue. Once the issue has been reproduced, click Stop to end the capture.

Figure 10: Initiate the Packet Capture

Then click Save to store the packet capture as a local file for later analysis.

Figure 11 : Downloaded PCAP from the Unlashed UI.

Once the file is downloaded, it will be saved in the Downloads folder. Extract the contents, and you’ll find folders containing the PCAP files. These files include detailed information on the association process for the end client , which will help you investigating if there is any incidents.

Note : Remember to remove the AP from the capture list and disable packet capture after completing this process.

By analyzing the packet exchange during the connection process, you can pinpoint where the failure occurs and take appropriate corrective actions. This method provides valuable insights into the interaction between client devices and APs in real time.

Unleashed Overview

In an Unleashed network, a RUCKUS Unleashed 'Master' Access Point acts similarly to a controller, managing all control functions. These settings are then propagated to the other APs in the network. If the Master AP go offline, a 'Member' AP will automatically take on the role of the Unleashed Master, assuming control and maintaining network operations.

Unleashed Support

-Bridge mode 128 APs and 2,048 clients.

-Gateway mode supports up to 25 APs and 512 clients.

-Dedicated Master

Overview Limitations from Zone Director

-IPv6 is not supported.

-No interface to communicate with SmartCell Insight analytics engine or SPoT location.

-No Northbound Interface to pass client authentication responsibility to an external entity.

-No WLAN groups.

What are the necessary conditions or prerequisites for an access point to successfully connect to an existing Unleashed network?

Connect the Member Access Point (AP) to the network, ensuring it is on the same VLAN as the Master AP. Upon powering up, the Member AP will engage in an election to determine if a Master already exists. It's important that the Member AP either matches or has a lower firmware version than the Master.

Additionally, it must be able to ping the Master AP and share the same country code setting.

Commands to check if a member Access Point is not joining to the Unleashed Network.

•  ping < Master_AP>
•  get version 
•  get boarddata : Display hardware version and system board information
•  get discovery-agent: Check if LLWAP protocol is enable.
• get countrycode :
• get director : show Master AP information.
• get election: shows the status of all Unleashed APs
• get syslog log

The same information can be collected on the Master AP.

• Ping <Member_IP>
• get version 
• get countrycode 
• get boarddata 
• get election 

Ruckus CLI on unleashed when SSH to the Access Points.

The 'ruckus>' CLI prompt indicates you are logged into the 'Master' Access Point. From here, you can navigate through various configuration modes to manage settings and preferences.

Enable:

ruckus#

Under enable mode we can go to different modes example:

ap-mode: Note under this mode you can run set-get commands.

ruckus(ap-mode)#

Config

ruckus(config)#

Under config there are some different modes

+Admin:

ruckus(config-admin)#

+System:

ruckus(config-sys)#

+Using the Mac-address of the AP: 

ruckus(config)# ap d4:bd:4f:01:bc:10
The AP 'd4:bd:4f:01:bc:10' has been loaded. To save the AP, type 'end' or 'exit'.
ruckus(config-ap)#

The 'rkscli:' prompt indicates that you are logged into a 'Member' Access Point. In this CLI, you can execute 'get' or 'set' commands to retrieve or configure the Access Point settings. For example:

Best Regards 

Fernando Vasquez 

1- Make sure the server has the necessary basic features installed.

2-Navigate to the Network Policy Server tab, access NPS (local), and choose the 'Radius server for 802.1x' option for both wireless and wired connections. Finally, select 'Configure 802.1x'

3-In this step, select 'Secure wireless connections' and customize the policy name to your preference. In this case, append 'DEMO' at the end of the policy name.

4-In this step, you need to configure the Radius Client by providing a friendly name, entering the IP address of the master Access Point, and optionally setting a password or using a password generation tool. Remember to save this configuration as it will be used in Step 9.

5-In this step, choose 'Microsoft Protect EAP (PEAP)' as the network access method

6- Next, leave the remaining options at their default settings, and conclude the configuration by clicking on the 'Finish' button.

7-Configure the “Connection Request Policies”

To configure the connection request policy, navigate to the 'Policies' section. Then, access the 'Connection Request Policy' folder and locate the policy is created with the same name. Double-click on it to access its properties. In the 'Properties' window, navigate to the 'Conditions' tab. Remove the 'Current' condition and any others if present. Add the 'Time' condition and select 'Permit all time'. Finally, click 'Apply' and then 'OK' to save the changes.

8-Configure Network policies

To configure the Network Policies access to “Network Policy” folder and locate the policy is created on the folder and locate the policy is created with the same name. Double-click on it to access its properties. In the 'Properties' window for this example, I choose to ignore the user properties dial and proceed to the 'Conditions' section. Here, I add the 'User Groups' option to use the Active Directory users.

In this part, you have the option to either use an existing group and its users or create a new group along with its users.

Optional step

How to create a group and users

Open Active Directory Users and Computers, then select the domain used in this case, cslab12.com. Navigate to the 'Users' folder, right-click on it, and choose 'New' > 'Group.' Finally, enter the required information

Reference : https://docs.commscope.com/bundle/sz-700-accessservicesguide-sz300vsz/page/GUID-D9E129C3-A6AF-433F-ABA3-81BD8A1CCA91.html

How to create an user

Navigate to the Active Directory of users and computers, then left-click on it. Next, select 'New,' followed by 'user’, and proceed to fill in the required information (username and password ).

In this case, we need to edit the 'Member of' properties of this user. Since I want this user to belong to the earlier created 'DEMO' group, we navigate to the user's properties, specifically the 'Member of' section. Subsequently, we add the group and configure it as the primary group.

Continue with the network policies configuration next, we will select the desired group and proceed to the 'Constraints' tab. Here, we will add CHAP as the authentication method.

9-Unleashed Configuration

In the Unleashed configuration, navigate to 'Admin and Services' and then 'Services.' Click on the plus (+) sign to add the RADIUS server and fill in the information based on the configuration we completed in Step 4. Ensure that the IP address points to the RADIUS server.

10- WLAN Creation

Navigate to 'Wi-Fi Networks' and select the tab for creating a wireless network. Fill in the necessary information accordingly. In this step, the only addition is to include the server that we created in Step 9 as the authentication server.

11-Wireless Client

After creating the wireless network, it's important to check the connectivity. Connect to the network and when prompted, enter the credentials of the created DEMO-USER along with the corresponding password. If the credentials match, you should be able to connect to the network without any issues.

This option is configured in the DHCP server and must be masked. Also, the vendor code and the length of the IP address must be specified in HEX.

RUCKUS vendor code:

- 06 for SmartZone

- 03 for Zone Director

Using this website you will quickly mask the IP address from IPV4 to dnsmasq values.  

For example, let's mask the IP address 192.168.0.200 using the website: the final value to enter in your DHCP server is "060d3139322e3136382e302e323030"

How did they get to such a result? 

1. Divide the IP Address: Start by splitting the IP address into its four individual parts: A.B.C.D.

   1. 192
   2. 168
   3. 0
   4. 200

2. Mask the decimal values: For each part, convert the decimal value to its corresponding hexadecimal representation. For instance:

   • Decimal 1 becomes "31"
   • Decimal 9 becomes "39"
   • Decimal 2 becomes "32" ...

3. Add Separators: Place "2e" (ASCII value for dot) between each pair of translated hex values.

4. Include Vendor Code and Length: Prefix the vendor code at the beginning (e.g., "06" for RUCKUS). Add the IP address length in bytes (e.g., "0d" for 13 bytes).

   Note: The length is 13 bytes since each pair of characters equals one byte.

5. IP Address Translation: The IP address "192.168.0.200" transforms into the hexadecimal string "3139322e3136382e302e323030".

6. Combining Elements: Combine all the translated parts to form the final hexadecimal representation.

Example for the IP address "192.168.0.200":

• Translated octets: "31", "39", "32", "2e", "31", "36", "38", "2e", "30", "2e", "32", "30", "30"
• Vendor code: "06"
• Length: "0d"
• Combined: "060d3139322e3136382e302e323030"

Visit this post to learn other ways to provision RUCKUS APs with the IP address of their controllers.

I have about 10 APs R550's running the latest firmware with 4 VLANs - we want to put certain people on certain VLANs only and prevent them from logging in otherwise.   The first group is about 50 mac addresses, the second is about 100 and the third is about 25 mac addresses.

We'd really prefer to import a mac address list rather than add 175 mac addresses 1 at a time.

Anyone know a way to import the CSVs?

How can we check this?  The data sheet of the device(s) !.
Let’s consider, RUCKUS ICX 7150-48P Switch, which has the following hardware specifications: 

• 48× 10/100/1000 Mbps RJ-45 PoE+ ports  
• 370 W PoE budget  
• 2× 10/100/1000 Mbps uplink RJ-45 ports  
• 4× 1/10 GbE uplink/stacking SFP/SFP+ ports 

 Which shows that,  It has a PoE budget of 370 W and there are 48 ports that can support PoE+ or 802.3at.

For more reading, refer : https://www.commscope.com/globalassets/digizuite/61729-ds-icx-7150.pdf 
Note that in this example we have considered 7150, but for other models such as 8200, 7550, etc. Please refer to the data sheets for the respective switch families.

Number of devices it can deliver PoE to.  

This relates to the PoE budget of the device and the type of Powered Devices (PDs) used. Nowadays, PDs typically come with PoE+ capabilities, although there are still some that support only PoE. The crucial factor is understanding the PD's capability to determine how many of them the switch can accommodate or power up. For instance, consider an Access Point (AP) rated for PoE+. When negotiating for PoE, the device communicates with the switch through the LLDP TLV field, specifying its class and power requirements. Based on this class, the switch allocates power accordingly.

The above reference is as per IEEE Documentation for PoE standards 802.3at and 802.3bt.  
Based on this, considering that the PD is PoE+ capable, on RUCKUS ICX 7150-48P that has 370 W PoE budget. 
We can calculate the below:  
PSE's budget = 370W 
PD's PoE Class = PoE+ that reserves max. of 30W at PSE  
Number of devices = PSE's PoE budget / PoE Class of the device = 370 / 30 = 12.3333 
It can power up to 12 PDs at PoE+ power level. Any additional PDs would not activate due to insufficient remaining power in the budget.

Now the question arises, why not define the power limit manually?  
    Strict manipulation can indeed bring up more PDs, but it carries a risk. After all PDs are operational and receiving optimal power, reallocating power back to the budget pool is possible. However, if a reload or power cycle of the Power Sourcing Equipment (PSE) occurs unexpectedly, PDs may encounter power-up issues. During the initial power-up or startup phase, the PSE delivers full power to the PDs. Consequently, some connected PDs may experience power shortages and struggle to come online.

Can it be done? And how?  
To configure the power limit manually on a interface based on power limit.  
Please do refer.  
https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GUID-58622E67-07D7-41E4-B4C6-A9B6F3EA8C74.html 
To configure the power limit manually on a interface based on class of the PD. 
Please do refer. 
https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GUID-155FABD5-F3C2-4579-ADBB-CC240997524A.html 

How does Ruckus address this?
Ruckus offers two well-known ways for Power Management methods for ICX line that are PoE capable.
Static Power Management:
Power is set aside for each powered device (PD) connected to switch ports when in static PM. This approach adheres to the previously discussed procedure, wherein the maximum power is set aside according to the linked power device's class. If the power reservation is not possible, even when the overall usage is less than the entire power budget, no new PDs will be powered. 
The ICX devices are configured or made available in this mode for PoE management Out of the Box. 

To overcome this, we have Dynamic Power management.  
Dynamic Power Management: 
Where this helps via having the power allocation done based on the consumption of the PD that’s connected.  Here power is not set aside for any ports in dynamic PM. Until the overall power consumption is within the ICX device's total power budget, PDs are turned on automatically.  
However here the switch will immediately shut down any PDs with low priority ports or, if all ports have the same priority, shut down PDs attached to higher-numbered ports in order to keep the total power consumption within the total power budget if the power consumption increases, either by increasing the power consumption of connected PDs or by adding new PDs. 

How to go about setting this?  
Do refer here:  https://community.ruckuswireless.com/t5/RUCKUS-Self-Help/How-to-enable-Dynamic-PoE-power-on-the-ICX-switches/m-p/68751 

There however is a third way, that is Hybrid Power Management. 
This is a mix of the above 2 methods and can be achieved by configuring static PM for a few of the ports and dynamic PM for a few of the ports. The way this works to differentiate between the two methods is based on the priority that is set for the specific interfaces, priority of 1 dictate that it uses static PM, as priority of 2 or higher dictates it uses dynamin PM. This priority can be set per interface or globally as well.  

Under this method, after enabling dynamic poe, below settings are needed enable Hybrid PM,
(1) to enable Static PM, use "inline power ethernet unit/slot/port priority 1" on those specific ports. 
Example: in config mode,  
Inline power ethernet 1/1/1 priority 1 
(2) to enable Dynamic PM, use a priority of 2 or 3 instead of 1 on those specific ports. 
Example: in config mode,  
inline power ethernet 1/1/4 priority 2 

Apart from this, there is also Perpetual PoE and Fast Boot PoE.
Perpetual PoE, where PoE power delivery to the equipment is uninterrupted, when the device is rebooting or reloading.  
Fast Boot PoE, where the PoE is delivered as soon as the switch is turned on, where the PD would not have to wait until the system is up.  
To enable this, Use “inline power poe-ha” in interface configuration prompt.  

For Further reading on PoE features on the ICX line-up, Click here,  

Abbreviations used:
PD - Power Device. 
PSE - Power Source Equipment also known as Endspan device. 
PoE - Power over ethernet. 
PoE Injector is also known as Midspan device. 

show commands:
1. show config
2. show running-config
3. show stack
4. show version
5. show chassis
6. show vlan
7. show inline power | inc stack/slot/port)
8. show interface brief
9. show inline power detail
10. show chassis
11. show lldp
12. show lldp neighbors detail ports all (for single port: ports ethernet stack/slot/port)
13. show fdp
14. show fdp neighbors ethernet stack/slot/port
14. show inline power emesg

General information to request:

What Powered Device (PD) types are connecting to the Power Source Equipment (PSE)
i.e. Model number, firmware version, serial number, manufacturer, PoE standard provides up to 15.4 W, PoE+ or PoE plus, provides up to 25.5 W of power?
And/or Power over HDBaseT (PoH), ratified in September 2011, extends PoE’s capabilities to deliver up to 95W?

https://support.ruckuswireless.com/software 

The advantage of the SZ controller is that if you need to upgrade to the newest version 6.1.1, you can still keep the EOL R600 AP on a separate AP Zone with the firmware 5.2.2 for this zone, while the newer APs are managed in zones with the appropriate version for them.

Need to upgrade de controller? Follow this step-by-step.

Customer Environment

APs and Switches deployed behind a firewall and inbound/outbound traffic needs to be allowed for successful communication between RUCKUS network devices and RUCKUS One.

Symptoms

Newly added APs and switches are in Never Contacted Cloud state, not joining RUCKUS One.

Resolution

To allow RUCKUS One to function properly, please configure your firewall to allow for outbound connectivity according to the following guidelines:
 

Outbound HTTPS (TCP 443) from APs and Switches to:

https://ap-registrar.ruckuswireless.com
https://sw-registrar.ruckuswireless.com
https://ocsp.comodoca.com
https://ocsp.entrust.net
https://ruckus.cloud
https://eu.ruckus.cloud
https://asia.ruckus.cloud
https://device.ruckus.cloud
https://device.eu.ruckus.cloud
https://device.asia.ruckus.cloud
https://storage.googleapis.com
http://ocsp.godaddy.com

Outbound SSH (TCP 22) from APs and Switches to:

device.ruckus.cloud
device.eu.ruckus.cloud
device.asia.ruckus.cloud

Network Requirements

The following list of firewall ports is required to allow APs to enable Cloud discovery and continued connection with the Cloud

Checking the firewall ports is the first step of troubleshooting if an AP is unable to connect to the Cloud or disconnects from the Cloud.

https://docs.cloud.ruckuswireless.com/ruckusone/userguide/GUID-D00EA4CC-7B8A-4F99-969B-2A5FB5DDB178-low.png 

If these information helped you in any way, please click on "KUDOs", so you can help other users.