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.

Diagnosis is possible using over-the-air monitoring. The packets get mangled by the R600 as it relays traffic between the wired and wireless netorks. The RAP deletes protocol-header bytes when forwarding mesh traffic across the RAP Ethernet boundary. There is a workaround possible, but it involves modifying the firmware running on the AP.

I created a support case for this behavior with more detail and a recommended fix, but I don't know if ZD will have any future releases.

I believe the bug affects these models of APs: R500, R600, R310, T300, T300e, T301n, and T301s when running these versions of ZoneDirector: 10.5.1.0.282, 10.5.1.0.279, 10.5.1.0.276

This might be the cause of the behavior described in this other post "Zonedirktor 1200 After RMA replacing, mesh ap´s no longer works" and it could be another possible reason for the KnowledgeBase article "Mesh AP unable to connect to a Root AP"

When a user goes through enrolment and gets a DPSK. When they then use that DPSK each device shows up as AccountDPSK-xxxxxx for the username:

Since the user went through an enrollment, CloudPath knows the username and we can use a POLICY to return the username attribute.

1. Create a RADIUS Attribute Group that associates the RADIUS value “User-name” to the variable ${USERNAME} make sure to modify the assignment behavior to add or replace:
2. Create a POLICY that returns that attribute:
3. Apply that POLICY to the DPSK pool:

    

During the next auth of that device, the returned value of the variable ${USERNAME} will be visible in the controller:

Thanks.

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.

This is an important security announcement.

A vulnerability in the web-based management interface of the RUCKUS AP product line could allow an
unauthenticated, remote attacker to execute a cross-site scripting (XSS) attack against a user that’s
logged on to the interface of an affected device.

A security bulletin was posted by RUCKUS Networks Security team on 28 Nov 2023. Please refer the same from the below link.

Security Advisory: ID 20231128

Fix is already available and customers are advised to upgrade to recommended version.

While you check and plan to upgrade your devices, we strongly recommend you to implement the workaround first, as this will immediately block the possibility of this security vulnerability.

Workaround: This vulnerability can be mitigated by disabling the web services (HTTP and HTTPS) on the AP. This can be done by using the AP CLI commands "set https disable" and "set http disable".

Note: For ZoneDirector and SmartZone APs, the web services components are disabled by default, once AP joins the controller.

Some quick facts:

1. Only Access Points are impacted due to this security vulnerability, not the controllers.
2. Disabling web server on AP (HTTP and HTTPS) guaranties no further possibility of an attack.
3. By default, any AP joining a RUCKUS Controller disables the AP web service, so your AP will only be impacted if you are using it in standalone mode or enabled the HTTP or HTTPS manually.
4. Only SmartZone, Zonedirector and solo (standalone) access point software versions are impacted.
5. RUCKUS Cloud and Unleashed APs are NOT impacted.

FAQs

• Q: What if I don’t have an active Support contract with RUCKUS – will I be able to upgrade my software?
  A: Yes. You will be able to obtain the recommended software that are available for your platform even if you don’t have a current support contract. At this time, a limited time manual support entitlement (1 day validity) will be provided, if your controller falls into the eligibility criteria for the upgrade. Option to upgrade with one day entitlement will be valid only for 30 days from the date of this post.
• Q: What is the eligibility criteria to get one time support exception?
  A: Your Controller (Not Access Point version) should be on a version which is impacted.
  B: Access Point model(s) for which you want to apply the fix should be supported by the recommended firmware version.
• Q: Post upgrade if I am facing any issues (other than controller/AP firmware upgrade) with my controller/Access points, am I eligible to get support?
  A: No, limited time support entitlement is valid only for obtaining the upgrade files and entitlement, so that controller/APs can be upgraded. No additional issues can be reported under limited time support entitlement. We strongly recommend you to purchase the support entitlement for your product, to get all the support benefits. 

If you have any queries, please use the comment section on this thread and we will be happy to answer and assist.

In this document will be found the best practice and support documentation to add a new ICX to the controller for the first time.

1: Your running version must be UFI, can be checked with the next command:

ICX#show version | include UFI

      (33554432 bytes) from Primary SPR08095h.bin (UFI)

2: The next 3 processes nginx, wmsgi and PySzAgtSrv.py must be Oper. State: Up and can be checked with the next command: hmon client status all-clients, However if the processes are down, we recommend ensuring the IMAGE you are using is UFI if not, upgrade to the UFI image, however if the image is UFI already, we require performing a reload or a factory reset in case the issue still persisted after reload, but if the issue persisted please contact our TAC team.

Working

No working:

3: Time must be configured, can be set manually or with NTP server

ICX#show clock

ICX# clock set 11:22:00 10-11-2023

ICX# configure terminal

ICX(config)# clock timezone us mountain

ICX# configure terminal

ICX(config)# ntp

ICX(config-ntp)# server 1.2.3.4

4: The Switch must be enabled to be discovered by the controller if not must be enabled.

ICX#show running-config | include registrar

ICX# configure terminal

ICX(config)# manager registrar

5: DNS must be configured can be checked with the next command: show running-config | include dns, however if there is not DNS, the public DNS must be configured.

ICX# configure terminal

ICX(config)# ip dns server-address 8.8.8.8

6: The Controller must be reachable as well the DNS

vSZ

ping registrar.ruckuswireless.com

Cloud:

ping device.ruckus.cloud

DNS test

ping x.x.x.x (DNS server IP address)

7: The Certificate must be installed, with the next command can be checking, and the message must be always Successfully verified, if not For ICX 7250, 7450, or 7750 models we can re-install the certificate, however a reload is required, and is recommended to have console access, for the other models we can factory reset, but if the issue persisted please contact our TAC.

 ICX(config)# crypto device-key-zeroize

ICX(config)# crypto device-cert-zeroize

ICX(config)#crypto key generate

ICX(config)#write memory

ICX(config)#reload

8: Now the unit is ready to be added, now if you are still having issue, make sure the IP address listed is the address to which the switch should connect, if not can be manually deleted and added.

ICX#show manager status

ICX(config)# no manager registrar

ICX(config)# no manager active-list

ICX(config)# manager active-list x.x.x.x

ICX(config)# manager registrar

ICX(config)# exit

ICX#manager connect

Firewall open ports

https://docs.commscope.com/bundle/ruckuscloud-userguide/page/GUID-7B79A19A-2419-4AE8-A4C7-329FF6C34A08.html

Set up DNS

https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GUID-7CF29E61-55F8-4578-A630-D2468235BB93.html

Set up the clock manually.

https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GUID-E670EE11-FBD6-4D1E-9099-6E231887D245.html

Customer Environment

Zone Director managed AP network where you would like to blacklist certain channels. This is mainly applies for ZD version below 9.5.

Symptoms

Resource group mapped to a user needed to revisited and modified

Resolution

After logging into the ZD CLI, enter into the ‘enable’ context, then the ‘debug’ context. To enable channel Blacklist feature run the below command:

remote_ap_cli –A “set blacklist [wifi0¦wifi1] [enable¦disable]" – It executes for all the ZD managed Aps.

remote_ap_cli –a MAC address of the AP “set blacklist [wifi0¦wifi1] [enable¦disable]" – It executes on the specifc AP.

Where:

wifi0 = 2.4Ghz radio

wifi1 = 5Ghz radio

Manually Blacklisting channels from channel selection:

To manually specify blacklisted channels use the command:

remote_ap_cli –A “set blacklist [wifi0¦wifi1] <ch> <option>”

Where <option>:

-1 = permanently add to the blacklist (will survive a reboot)

0 = clear channel from blacklist

1 = temporarily add to the blacklist (won’t survive a reboot)

Note : From 9.5 and above firmware version, we can block the channel from the ZD GUI :: Configure :: Access Points, click on the particular AP, under 'Channel Range Settings' you can see that option.

This is part of the symptom you will see in the AP support log:

Aug 19 17:58:11 clbd sta join XX:XX:XX:XX:XX:XX wlan3(YY:YY:YY:YY:YY:YY) 1 rssi=(25 42) 2g(0x0 4 31) 5g(0x0 4 13) 
Aug 19 17:58:12 clbd sta leave XX:XX:XX:XX:XX:XX wlan36(YY:YY:YY:YY:YY:YZ) rc=1 rss(20 0) 0 pkt(3588 12841) byte(498065 12750895) 
Aug 19 17:58:15 clbd sta join XX:XX:XX:XX:XX:XX wlan36(YY:YY:YY:YY:YY:YZ) 116 rssi=(11 22) 2g(0x0 4 29) 5g(0x0 4 12) 
Aug 19 17:58:16 clbd sta leave XX:XX:XX:XX:XX:XX wlan3(YY:YY:YY:YY:YY:YY) rc=1 rss(43 0) 0 pkt(1011 2437) byte(101751 2409641) 
Aug 19 17:58:20 clbd stamac=XX:XX:XX:XX:XX:XX bssid:YY:YY:YY:YY:YY:YZ score=0 oldstate:NONE newstate:GOOD

I tried ensuring that the airtime was decongested and free of interference, the RSSI was good, the SNR was good, and coverage for roaming was good. There weren't any notorious sources of interference, high retransmission rates, or physical errors in the APs.

For troubleshooting, I even enabled features like 'RSSI threshold' and 'Transient Client Management', but none of those were causing any difference in the constant and annoying disconnections.

So, I started to suspect more and more that there was an issue with those Apple devices, especially when there wasn't an obvious reason for this problem. I began to research within online forums and Apple support pages, an I found many people were complaining about this issue, but there wasn't an actual resolution or valuable comments from the Apple support team until I found this Apple support forum.

This is the workaround that worked for every customer I have suggested it:

In your iPhone:

1. Go to Settings, scroll down, and select 'Privacy and Security.'

2. Select 'Location Services' and make sure the toggle is switched on.

3. Scroll down and select 'System Services.'

4. Switch off the toggle for 'Networking and Wireless.'

5. Forget the Wi-Fi network and then reconnect.

After applying these steps in iPhones running iOS 16.1 the issue was solved immediately. However, the computers kept disconnecting. Then, an upgrade on the computers to the MacOS Ventura version 13.6, finally solved the disconnection issues for the MacBooks as well.

I hope this article is useful if you're experiencing similar issues.

Initially, need to connect with the Server Manager. Subsequently, we will install the DHCP feature. The installation choices are discretionary; I plan to implement a role-based approach with a focus on the "basic" configuration.

At this point, we will proceed with the installation of the DHCP function.

We will incorporate the essential features as required.

Install

We should expect a warning. In such a situation, we will proceed by selecting "commit" and then closing it.

Navigate to the Tools tab and proceed to choose the DHCP option.

This action will launch the DHCP manager, providing us with the capability to generate scopes and configure DHCP groups based on our specific preferences.

I will now conduct a demonstration of a fundamental IPv4 configuration. Please note that these values can be adjusted to align with your preferences and the necessary configurations.

To proceed, select the "IPv4" option, followed by "New Scope."

I will configure the scope range  from the following range 10.0.0.3 to 10.0.0.30, ensuring that the devices are assigned valid IP addresses within this range.

The subsequent options are provided on an optional basis:

+Exclusion addresses

+Lease time

+DHCP options

+Default Gateway

+DNS

+Server

I will incorporate the feature to assign a default gateway to the client's IP configuration.

In the DNS server there are some by default you can delete them and add the directory of your preference

You have the choice to enable DHCP here, but if you prefer, you can opt to activate it later. For now, I'll proceed with its activation.

After setting up the DHCP server, you will notice its presence within the administrator interface. From there, you'll be able to customize the configuration according to your preferences, review leasing information, monitor statistics, and easily manage additions or removals of configurations as needed.

If your APs will be managed by a controller, you will need some way to ensure that the APs can discover the controller on the network. There are several different ways to do this, and the specific controller user documents contain more details on discovery for that particular controller product family.

This section provides a brief overview of the options available for controller discovery.

Ruckus Cloud

Ruckus APs discover Ruckus Cloud controllers by querying the Ruckus Cloud AP Registrar (ap-registrar.ruckuswireless.com) via HTTPS to learn the Ruckus Cloud address. APs will search for a Ruckus Cloud controller more frequently after initial boot up, and less frequently after the first 14 days.

Standalone APs will query the Registrar with the following frequency:

SmartZone

SmartZone APs discover SmartZone controllers using any of the following methods:

ZoneDirector

1. Access debug mode:

ruckus> ena
ruckus# debug
You have all rights in this mode.
ruckus(debug)# remote_ap_cli

usage: remote_ap_cli [-q] {-a ap_mac | -A } "cmd arg1 arg2 .."
excute AP CLI command in remote AP
-A ; all connected AP's
-q ; do not show result
cmd ; Ruckus CLI, e.g. "get station wlan0 list"
remote_ap_cli
ruckus(debug)#

For instance, retrieve uptime for all APs:

ruckus(debug)# remote_ap_cli -A "get uptime"

2. Enclose the standard AP CLI command you would typically use directly on the AP's CLI within double quotes. For instance, in this case, use 'get uptime'.

Here is an example from the Command Reference:

ruckus(debug)# remote_ap_cli -A "get director"
---- Command 'rkscli -c "get director "' executed at c0:c5:20:3b:91:f0
------ ZoneDirector Info ------
Primary Controller   : n/a
Secondary Controller : n/a
DHCP Opt43 Code      : 3

The information of the most recent Zone Director:
  [1] 192.168.40.100

  AP is under management of ZoneDirector: 192.168.40.100 / c0:c5:20:18:97:c1,
  Currently AP is in state: RUN
OK
---- Command 'rkscli -c "get director "' executed at c4:10:8a:1f:d1:f0
------ ZoneDirector Info ------
Primary Controller   : n/a
Secondary Controller : n/a
DHCP Opt43 Code      : 3

The information of the most recent Zone Director:
  [1] 192.168.40.100

  AP is under management of ZoneDirector: 192.168.40.100 / c0:c5:20:18:97:c1,
  Currently AP is in state: RUN
OK
---- Command Execution Summary:
         success: 2
         failure: 0
           total: 2
ruckus(debug)#

Prerequisite: Switch should also be capable of providing higher speeds such as 2500 Mbps, 5000 Mbps etc.

Using R720 AP as an example here. The PoE port of the R720 AP can provide speeds up to 2500 Mbps. Whereas the second ethernet port is limited to max speed of 1000 Mbps.

In such a case, if LCAP/ LAG is enabled on the controller under AP specific configuration for R720, the PoE port of the AP will not provide 2500 Mbps, even if the switch port is configured to provide 2500 Mbps duplex speeds.

With LACP enabled, both ports are bound together and must run at the same speed. Here 1000 Mbps becomes the limiting speed. Hence the switch port has to configured to use 1000 Mbps to bring the AP back online on the network.

Conclusion: If LACP or a aggregation on AP ports is not being used, please make sure to disable LACP configuration under AP model specific setting to ensure the AP can utilize its higher link speed port to its fullest capability.

FTP uses TCP (Transmission Control Protocol) for data transmission, which provides error checking and correction, ensuring that the entire file is correctly received. This makes FTP more reliable and faster for transferring large files or over networks with high error rates.

Here is a quick guide to deploying an FTP server on your computer:

1. Download and install the Mobaxterm app.

2. Go to 'Network Services' and click the configuration gears for the FTP server.

3. Select the Folder for the file location and configure a username and password. I recommend disabling the option 'Prompt me before accepting any incoming connections' and enabling 'Allow anonymous connections'.

4. Click 'OK' and 'Start'. The server will start. It will also start a time countdown that will disable the FTP service once this gets to 0.

5. Your FTP server is ready for file transfers.

Mobaxterm is an amazing app with many tools that can help us on our daily tasks. Take a look at this KB so you learn how to use it for SNMP operations on your ICX switch.

AP WLAN oversubscribed

AP [AP-name@M:AC:AD:DR:ES:00] does not have enough capacity to deploy all WLANs. Only maximum WLAN number of the AP can be deployed.

These logs may be seen on the AP CLI:

Jul 13 21:30:50 HOME-R350 daemon.warn libapcfg[11330]: apcfg_set_wlan_cfg:10328 Can't find wlan slot index. Reach the maximum support number[8]. wlan id:[493].
Jul 13 21:30:50 HOME-R350 daemon.info libapcfg[11330]: @@114,apWlanOversubscribed,"apMac"="D4:BD:4F:01:D4:A0",

This is because Access Points (APs) have a finite number of SSIDs they can broadcast per radio band. This limit is specified in the datasheet of each AP model. For instance, consider the datasheet for the AP R350:

The AP R350 can only broadcast a total of 16 (user-configured) SSIDs. The total count of SSIDs includes those broadcasting on 2.4 GHz and 5 GHz bands separately. In other words, there are 8 SSID slots per radio band. This implies that if you have a WLAN named 'wlan-name' that's broadcasting on both radio bands (2.4 GHz and 5 GHz), it's utilizing two of the available SSID slots.

There are additional SSIDs reserved for other functions like mesh networking and recovery purposes. These SSIDs are not considered in the maximum SSID capacity.

You can verify the WLANs your AP is currently broadcasting by using the AP CLI command 'get wlanlist' to check the actual number of SSIDs broadcasting. But make no mistake, this command ONLY shows configured and enabled WLANs. There could be also configured and disabled WLANs occupying SSIDs slots.

Here is an example from the AP R350. This Access Point seems to be using using 4 of the available 8 slots for 5GHz SSIDs ('Internet', 'ruckus-pruebas', 'wlan1', 'wlan2'):

Yet, this AP is already oversubscribed. I can confirm that by checking the SSIDs in WLAN group assigned to this AP.

In the controller, I reviewed the WLAN group and confirmed it has got a total of 10 configured WLANs. 4 WLANs are enabled, 6 WLANs are disabled.

Resolution:

If you have confirmed your AP is actually oversubscribed, the recomendation is to reduce the number of SSIDs.

It could be possible that moving an AP between different AP Zones could trigger a false positive event, indicating that the AP is oversubscribed. If the actual number of configured WLANs is within the AP's capacity, it's recommended to reset the AP to its factory defaults to clear the false positive and let it onboard the controller again.

This is an important security announcement.

A critical vulnerability was found in the web services component in earlier RUCKUS AP software. If the
affected web services component is enabled on the AP, this vulnerability allows an attacker to perform
remote code execution (RCE) and cross-site request forgery (CSRF).

A security bulletin was posted by RUCKUS Networks Security team on 8th Feb 2023. Please refer the same from the below link.

https://support.ruckuswireless.com/security_bulletins/315

You can also refer our Technical Support Response Center page from the below link. It has more information.

https://support.ruckuswireless.com/rce-csrf-ruckus-tech-support-response-center

Please be informed, all the impacted devices were already fixed long back. However, if you are running your RUCKUS APs on an impacted version, please refer our Technical Support Response Center page and upgrade your controller/APs to the recommended versions.

While you check and plan to upgrade your devices, we strongly recommend you to implement the workaround first, as this will immediately block the possibility of this security vulnerability.

Workaround: This vulnerability can be mitigated by disabling the web services (HTTP and HTTPS) on the AP. This can be done by using the AP CLI command "set https disable" and "set http disable" command.

Note: For ZoneDirector and SmartZone APs, the web services components are disabled by default, once AP joins the controller.

Some quick facts:

1. Only Access Points are impacted due to this security vulnerability, not the controllers.
2. Disabling web server on AP (HTTP and HTTPS) guaranties no further possibility of an attack.
3. By default, any AP joining a RUCKUS Controller disables the AP web service, so your AP will only be impacted if you are using it in standalone mode or enabled the HTTP or HTTPS manually.
4. Only SmartZone, Zonedirector and solo (standalone) access point software versions are impacted.
5. RUCKUS Cloud and Unleashed APs are not impacted.

If you got any queries, please use the comment section on this thread.

Thank you!

The issue is the iPad get disconnected from WiFi. The device doesn’t indicate it is disconnected but if the WiFi is turned off and back on again the iPad starts working immediately. The issue is random and can happen with a dozen or so devices a day or less.

This issue wasn’t as bad last year. We replaced our R700 with R550 units. We have an AP per classroom in the rooms having issues. I am trying to figure out if there is some setting in Ruckus that could help. I cannot think of anything to do on the iPad side.

These usernames and passwords are key sensitive, please use capital letters where necessary

Normally, the default passwords will be found on a sticker on the inside of your media panel or cabinet, however, sometimes the default password is not always set correctly. We have compiled a list of the common passwords. Please note that these passwords are key sensitive.

If this Wi-Fi network name or password doesn't work, has been forgotten or is unknown, you will need to reset your Wi-Fi access point to be able to set them back to match those on the sticker or to set new values.

Reset Process: https://www.youtube.com/watch?v=vFD_ByQWGH0

Configuration Process: https://www.youtube.com/watch?v=z4zbJcBSuuw&t=147s

Configuration Reference: https://docs.ruckuswireless.com/unleashed/200.1.9.12/t-LogInRunSetupWizard.html

Logs on firewall don't show any traffic in/out for VLAN 132 subnet.
Can ping from switch 10.10.8.2 --> 10.2.132.1
It seems like a WIFI config issue but neither Ruckus or Sophos are part of our normal stack so could be an issue in wifi/switch/firewall.

Thanks for your help!

Equipment
ZD1200  v10.5.0.0 build 212
Switch: Ruckus icx7150-48zp - 10.10.8.2

Firewall: Sophos XG230
VLAN1:        10.10.8.1 on br0
VLAN 132:   10.2.132.1 on br0.132 
DHCP Server: enabled on VLAN132

FW Rules

Zone: WIFI

Allow imcp to br0.132,
icmp to to WAN/Any

Any service to WAN from 

Switch Config

sw 1/1/10 AP2: untagged vlan1, tagged vlan132
sw 1/2/5 Uplink to sophos: untagged vlan1, tagged132

PORT-VLAN 132, Name WIFIGUEST, Priority level0, On
Untagged Ports: None
Tagged Ports: (U1/M1) 1 2 3 4 5 6 7 8 9 10 11 12
Tagged Ports: (U1/M1) 13
Tagged Ports: (U1/M2) 1 5

WLAN Config

Tx. Rate of Management Frame(2.4GHz) = 2.0Mbps
Tx. Rate of Management Frame(5GHz) = 6.0Mbps
Beacon Interval = 100ms
SSID = xTest
Description = TEST
Type = Standard Usage
Authentication = open
Encryption = wpa2
Algorithm = aes
Passphrase = testing123
FT Roaming = Enabled
802.11k Neighbor report = Enabled
Web Authentication = Disabled
Authentication Server = Disabled
Called-Station-Id type = wlan-bssid
Tunnel Mode = Disabled
Background Scanning = Enabled
Max. Clients = 100
Isolation per AP = Enabled
Isolation across AP = Enabled
Zero-IT Activation = Disabled
Priority = High
Load Balancing = Disabled
Band Balancing = Disabled
Dynamic PSK = Disabled
Rate Limiting Uplink = Disabled
PerSSID Rate Limiting Uplink = 50
Rate Limiting Downlink = Disabled
PerSSID Rate Limiting Downlink = 0
Auto-Proxy configuration:
Status = Disabled
Inactivity Timeout:
Status = Enabled
Timeout = 5 Minutes
VLAN-ID = 132
Dynamic VLAN = Disabled
Closed System = Disabled
Https Redirection = Disabled
OFDM-Only State = Disabled
Multicast Filter State = Disabled
Directed Multicast= Enabled
802.11d State = Disabled
Force DHCP State = Disabled
Force DHCP Timeout = 10
DHCP Option82:
Status = Disabled
Option82 sub-Option1 = Disabled
Option82 sub-Option2 = Disabled
Option82 sub-Option150 = Disabled
Option82 sub-Option151 = Disabled
Ignore unauthorized client statistic = Disabled
STA Info Extraction State = Enabled
BSS Minrate = Disabled
DTIM period = 1
Directed MC/BC Threshold = 5
Call Admission Control State = Disabled
PMK Cache Timeout= 720 minutes
PMK Cache for Reconnect= Enabled
NAS-ID Type= wlan-bssid
Roaming Acct-Interim-Update= Disabled
PAP Message Authenticator = Enabled
Send EAP-Failure = Disabled
L2/MAC = No ACLS
L3/L4/IP Address = No ACLS
L3/L4/IPv6 Address = No ACLS
Precedence = Default
Proxy ARP = Disabled
Device Policy = No ACLS
Vlan Pool = No Pools
Role based Access Control Policy = Disabled
SmartRoam = Disabled Roam-factor = 1
White List = vlan132
URL Filtering = Disabled
Application Recognition & Control = Disabled
Apply ARC Policy = NO POLICY
Client Flow Data Logging = Disabled
Wlan Bind = all
Client Connection Data = Disabled
Transient Client Management = Disabled
80211w-pmf = Disabled

WhiteList: vlan132
whitelist

In this self-help topic I will explain what to do when Zone director suffers hardware failure and APs are down, while you get ZD replacement.

There are two ways to temporarily restore the APs with limited functionality, while you get the ZD replacement.

1. Convert your APs to Unleashed code (AP models must support Unleashed firmware).
2. Convert your APs to stand alone firmware and configure individually (works irrespective of AP model).

Option one: Convert APs to Unleashed and manage from single master AP.

1. Factory reset specific APs or all APs (in case of big network you may want to follow this to critical area APs only). Refer our community thread from here to know more about how you can factory reset a Ruckus AP using AP CLI or physical button reset.
2. Download the compatible Unleashed firmware as per your AP model from Ruckus support web site (Note: If you have mixed AP models where some are supported in Unleashed and some or not, you may not be able to restore all the APs).
3. Login into each AP using web browser, go to Maintenance >> Upgrade >> Local >> Browse the Unleashed model specific firmware file and complete the upgrade.
4. Configure the very first AP (post upgrading to Unleashed) and this will become your Unleashed master AP (Controller AP). For configuration help refer quick setup guide from here and user guide from here.
5. Now upgrade rest of the APs same way. If 1st AP upgraded and configured as Unleashed master (Step-3 and 4) and rest of the APs are on same subnet then rest of the APs will join Unleashed master by its own.
6. Till you get your ZD replacement, you can manage the network from Unleashed master AP. Once you get the replacement, downgrade APs to standalone firmware and APs should rejoin the ZD.

Limitations:

• Only supported APs can be upgraded to Unleashed.
• APs must be in same IP subnet.

Option two: Convert APs to standalone mode and manage individually

1. Same as step-1 of option one.
2. Download the stand alone firmware from support site, as per your AP model.
3. Now login into each AP using web browser, go to Maintenance >> Upgrade >> Local >> Browse the model specific standalone firmware file and complete the upgrade.
4. Configure each AP individually.
5. Use the APs in stand alone mode while you get replacement for your ZD. Once you get replacement, configure it in isolated network and then place it back to the network. All the APs should reconnect (if AP/ZD both are in same IP subnet).
   • If AP/ZD are in different subnets, use DHCP option 43, or configure DNS or manually configure controller IP in each AP (set director ip xxx.xxx.xxx.xxx.xxx).

Limitations:

• AP cannot be managed centrally. Means you must configure and manage each AP individually.
• Since APs will be managed in stand alone mode, roaming will not work.

For any further assistance, reach out to Ruckus Support.

Follow the below steps:

1. Note down the below details of your current controller setup.
   • Controller type (virtual SmartZone, SmartZone, ZoneDirector, Unleashed).
   • Controller firmware version (Note: If you are using v/SmartZone then controller and AP version can be different).
   • AP models in use.
   • AP Zone version (Only applicable for v/SmartZone).
2. Now decide which version you want to upgrade to, depending upon below points:
   • Any bug/known issue on exiting version which is fixed on new version
   • Enhancements and stability.
   • New features
3. Review the release notes of the desired upgrade version. For example, assume my virtual SmartZone is on 5.1.2 and I decided to upgrade to 5.2.2 version.
   1. Go to https://support.ruckuswireless.com >> Documentation >> Choose the product (vSZ for the example) from the dropdown menu >> Now click on “Documents” tab >> from “Show” drop down menu, select desired version (in our case we want to upgrade to 5.2.2, so we need to select 5.2).
   2. Now locate the “release notes” of the 5.2.2.0.317 version (it is the latest controller version on 5.2.2 release at the time or writing this topic) and “Upgrade guide”. Open both the PDF files.
4. On upgrade guide, review below sections.
   1. SmartZone Upgrade Paths – This will tell you if your controller can directly upgrade to 5.2.2 version or not.
      
      
      
   2. Hypervisor Hardware Performance Requirements (Only applicable to virtual SmartZone) – This will tell you if you need to increase VM hardware resources for vSZ.
      
      
      
5. Open release notes, review below sections:
   1. Supported AP Models
      
      
      
   2. Unsupported AP Models (check this section if you have any matching AP models which are no longer supported on this version).
      
      
      
   3. Known Issues – These are the issues which are known to this version and Ruckus engineering is working to fix them in future releases. This also provides information related to Caveats and Limitations.
      
      
      
   4. Changed Behavior – This section explains changed behavior on this release.
      
      
      
   5. Resolved Issues – Refer this section to see what known issues are fixed on this release.
      
      
      
   6. Interoperability Information
      
      
      

Some other important points:

• There are also other sections which may be applicable to your setup:
  • Switch Management Feature Support Matrix
  • IoT Suite
• Provided details in this self-help topic is only focusing major component of a pre-upgrade check.
• We strongly recommend users to read complete release notes and upgrade guide carefully, before proceeding for the upgrade.

In above example, I have explained what to look for in the release notes or upgrade guide, before upgrading the controller.

This example is for virtual SmartZone (vSZ), as vSZ upgrade is bit complicated than other controllers like ZoneDirector and Unleashed, however, one should read the information on release notes and upgrade in the same way, as explained in this self-help topic.

Queries? Start the discussion and we will be here to help!