I´ve added a guest WLAN with success but, when user try to connect to it to generate their credentials the login/portal page that the https://<ruckus>/guestpass presents has a Ruckus logo and seems that changing in the Guest Wlan configuration makes no difference. 

Why I can´t customize the logo so my Guests know that the login page belongs to my company? I tried from the CLI but it doesn´t allow and it wasn´t much of help at all. 

Thanks.

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.

We have 2 ZD3025, version iz 9.12.3.0 build 61. We would like to configure Guest Pass. As I know I did all configuration, but this service doesn't work.

Guest Access Configuration:

SSID Configuration:

Role Configuration:

User Configuration:

Did I miss anything? Because Guest Pass doesn't work. 

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!