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.

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.

Fig 1 - Node join validation error

Environment - This example is from a vSZ-E (Essentials) with firmware 6.1.2 and running on VMWare ESXi Hypervisor. However, it is also applicable to vSZ-H (High-Scale) running any firmware version and deployed on any supported Hypervisor platform.

Resolution and Explanation - Make sure that VM Resource level of all the nodes of a vSZ cluster are the same. The Resource level matrix can be found on the respective firmware version's Upgrade Guides. For instance, vSZ-E 6.1.2 version has 1, 1.5, 2  and 3 as the Resource Levels that is dependent on the RAM, Disk size and vCPU per node :-

Fig 2 - Resource Level Matrix of vSZ-E

In this case, it was found that the vSZ node trying to join the Cluster had 21 GB of RAM allocated which brought it to Resource Level 3, while the existing Cluster Node had only14 GB of RAM allocated which means it was running on Resource Level 1. Therefore, a node with Resource Level 1 could not join a Cluster on Resource Level 4. 

Fig 3 - RAM allocation to vSZ node

After shutting down the instance and lowering the Memory to match the resource level of Cluster, the new vSZ node joined without any issue.

Regards,

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.

• vSZ-H version : 6.1.2.0.404
• Windows Server 2016

Setup Procedure:

This demo explains the configuration steps to authenticate wireless clients using 802.1x- SZ/vSZ by configuring NPs policy on a Windows server.

1-Make sure if the below features are 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 vSZ IP address, 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

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

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-Smartzone/ Virtual Smartzone configuration

In the SZ/vSZ configuration, navigate to “Security” ->Authentication->Proxy(SZ Authenticator)/ Non-Proxy(AP Authenticator)(I am using ' Proxy(SZ Authenticator) in my example

NOTE: Proxy(SZ Authenticator)  is used when APs send authentication or accounting messages to the controller and the controller forwards these messages to an external AAA server. A non-proxy (AP Authenticator)AAA server is used when APs connect to the external AAA server directly. 

Click on “+Create “ button

Enter the NPS server details and make sure that you enter the same shared secret as you have entered in NPS server

10- WLAN Creation

Navigate to “Network->  Wireless LANs”and select the desire zone and click on “Create” tab . Fill in the necessary information accordingly.

In my demo, I used High scale hence the Realm Proxy profile must be created so that the Realm Proxy profile would show in the drop down under the Authentication Service

How the Realm Proxy profile can be created? please check the below details

Click on First Realm ->“Configure” -> Under “Service”, make sure, you select the right NPS 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.

Regards,

Leimapokpam Ambika

Prerequisites:

• 802.1x SSID with Cloudpath as AAA with default ‘Radius options’
• Cloudpath 5.7 and above
• Vsz/sz 5.0 and above
• Segregate the locations using WLAN/AP group.

In SmartZone controller:

Go to > WLAN > Group 1 > Edit > Select WLANs > Toggle ‘NAS-ID’ to ‘User Defined’ then mention ‘Group1’  (Required attribute value)

In Cloudpath:

Step 1: Go to >  Configuration > Policies > RADIUS Attribute Groups > Add RADIUS Attribute Group > Under ‘VLAN ID’ mention desired VLAN

Step 2: : Go to >  Configuration > Policies > Policies > Add Policy > NAS Identifier (regex): ‘Group1’ (Mention the ‘User Defined’ value set as ‘NAS-ID’ in Vsz WLAN group)

Step 3a: If Certificate based Authentication

Go to > Certificate Authority > Manage Templates >  Certificate Template > Manage > Radius Policies > +Assign Policy ‘Group1’

Step 3b: If eDPSK based Authentication

Go to > Configuration > DPSK Pools > Manage > Radius Policies > +Assign Policy ‘Group1

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.

Recently we have come across several queries if we can upload 3.6.2.X AP Patch on SZ-144 or any other controller running the 6.1.1.0.595 version.

Query: Can we upload 3.6.2.X AP Zone firmware on SZ-144 running 5.2.2.X or 6.1.1.X?

Answer: Yes, we can manage the 3.6.2.X AP Zone version on SZ-144 running 5.2.2.X and 6.1.1.X.

Some key points:

• The minimum supported firmware version for SZ-144 is 5.2.1.X.
• Due to a new feature enhancement on 6.1.1.0.959, we can now also manage 3.6.2.X AP patch firmware onto SZ-144 and other vSZ/SZ platform controllers.
• Other controllers like vSZ-E/vSZ-H/SZ-100 etc. may or may not have AP Zone version 3.6.2.X (carried from the previous upgrade path), however, the below steps are applicable for such controllers as well where we can upload the 3.6.2.X AP/or any other AP patch version onto those controllers too.
• The AP patch upload procedure as shown below is a generic procedure and can be used to upload any AP patch firmware on the respective supported controller versions.

This article shows how we can upload an AP Patch onto the SmartZone controller.

In order to show the AP patch upload procedure, I have taken SZ-144 running on 6.1.1.0.959 firmware and the AP patch version as 3.6.2.x AP:

1. Download the 3.6.2 AP patch from the Support Portal link below:-

https://support.ruckuswireless.com/software/3068-smartzone-ap-patch-for-post-3-6-2-patch-2-scg200-sz300-sz-100-vsz

2. Upload the AP patch:-

Login to the controller GUI --> Administration --> Upgrade --> AP Patch --> Browse the File (patch downloaded) --> Click Upload :-

3. Apply the AP patch:-

Once the AP Patch is uploaded (from step2), the “Apply Patch” button gets highlighted (as shown below):

4. Create a New AP Zone with the AP patch version running 3.6.2.x:-

Once the Patch is applied to the controller, it is time to apply the patch to the existing AP zone or to create a new AP zone with that applied AP patch.

I have shown how to create a new AP Zone using the applied AP patch version:-

NOTE:

1. APs will reboot if we move the APs to the newly created AP zone with a different version and/or upgrade the AP zone with the applied patch. Hence schedule a maintenance window before making this change.
2. We cannot upload the AP patch lower than 3.6.2.x on a 6.1.1.0.959 Controller firmware (Example: 3.6.1.X cannot be uploaded onto the controller running on 6.1.1.0.959).

3. The legacy APs supported only till the 3.6.2.X version will not automatically join on SZ-144 even if we have the AP patch applied because the Default Zone will always be on the higher version (higher than 3.6.2.X).
4. Hence to register the AP to the SZ-144 on the Old AP firmware Zone, we must create an AP registration rule. Refer to the forum post on how to create an AP Registration Rule

This feature is designed to collect logs from various ICX modules, which can then be shared with technical support for thorough investigation. RUCKUS advises running support save prior to firmware upgrades to ensure the availability of essential information in the event of any complications.

Available options :

1) TFTP / SCP 

This option facilitates the retrieval of Support Save files through an external server using TFTP or SCP.

Command example:

TFTP :

supportsave all <Tftp_IP_Address> <File_name>

SCP :

supportsave all <SCP_IP_Address> <File_name>

Official data: https://docs.commscope.com/bundle/fastiron-09010-debugcommandref/page/GUID-461F5776-AB07-4D39-924D-EE4F0C425FF9.html

Video link as reference: https://www.youtube.com/watch?v=QndYv7igZe4

2)  Via Smart Zone / Virtual Smart Zone

If the Switch is connected to a Smart Zone or Virtual Smart Zone, the download can be initiated from the controller dashboard via web.

Network > Switches

If the switch is part of a specific group, choose that group, and then select the switch on which you want to save the support save.

Next, click on 'More', and then select the 'Download Support Logs' option.

Upon clicking, an option will emerge, asking whether you wish to download the file. Subsequently, the file will be downloaded to your local machine.

3) Via Web UI

This option is only available for versions 9010 or higher.

Login into the Web UI in the ICX

Management > Infra.

In the SUPPORT SAVE panel, click on 'Start' to start downloading the files.

Note: To cancel an ongoing supportsave operation, click 'Cancel'. While the cancellation is in progress, the 'Start' and 'Cancel' options will be unavailable. These options will become accessible again once the cancellation is complete.

Note: If you are running supportsave from the web interface for the first time, you must select Allow in the dialog box requesting permission to download multiple files to start the multiple file download.

Once the file is downloaded, it will be in the 'Downloads' folder in the local machine.

Official data: https://docs.commscope.com/bundle/fastiron-10010-webguide/page/GUID-06CD7A36-3E4D-48EE-8A02-D29C59069989.html

As a Ruckus TAC engineer, I would like to share a knowledge article about how to hide the SSID on smart zones.

We can access the option to hide the SSID from the controller's GUI and CLI.

Hide SSID from Controller GUI:

In controller GUI we can access the option under below path:

Wlan >> (select wlan) >> configure >> Advance options >> Broadcast SSID

To hide the SSID, we must disable this option, and to enable SSID, we must enable it.

Hide SSID from Controller CLI:

Similarly, we can access the option via the controller CLI with the following commands:

vSZ-E-31(config)# zone <zone name>

vSZ-E-31(config-zone)# wlan <wlan name>

vSZ-E-31(config-zone-wlan)# hide-ssid

Below is the example form my controller:

We can see and check the SSID hide configuration from the AP support logs using the logs lines below:

wlans/wlan0/wlan-ssid-hide='1'

wlans/wlan32/wlan-ssid-hide='1'

Below is an example from my AP support logs:

Cause: The actual filename of the backup was renamed to “vSZ_cluster_backup.bak”

Explanation: By default, when SZ/vSZ generates a Cluster-backup, it uses the following naming convention: -

dateTime_version_bladeUUID.bak (date is in the format of yyyymmdd & time in the format of hhmmss where y is the year, m is the month, d is the date, h is the hour, m is the minute & s is the seconds which corresponds to the date & time this cluster backup was generated).

Following is an example of a valid filename:

20240106180740_6.1.1.0.959_0c1db731-3366-4cff-a8e7-0de3068d9951.bak

Therefore, when we upload a Cluster-backup to SmartZone, it first parses through the file name and ensures that the filename contains at least the two mandatory fields - “dateTime_FirmwareVersion” in the correct format and then it decides if this is a valid file or not. So, it’s important to keep the filename in the original format and not change it.

In case you have already edited the filename by mistake (which is not recommended), and you do not know the original filename, you can simply rename the file in the recommended format by giving it a “dummy” date-time and “actual” firmware version. Note that SmartZone would use the same parameters to decide when this backup was generated.

Regards,

( Mail To：address1@lab.com & address2@lab.com)

vSZ version：6.1.2

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.

• Adding AP Licenses on the virtual controllers from LiMAN portal
• How to activate RTU and AP Licenses on vSCG/vSZ, vSPOT, SCI
• LiMAN License Transfer on a vSZ/SZ/SCI/vSPoT
• Insufficient AP support licenses warning message while upgrading SmartZone
• List of basic support and license required for vSZ, vSPoT and SCI
• License Warning messages on vSCG/SZ
• How to Activate and Apply Ruckus Licensing on SmartZone OS
• How to Download License for virtual controllers from LiMAN portal
• Uploading AP Licenses on the virtual controllers
• SZ license transfer post RMA
• AP Support License for Firmware Version 5.2 and above
• LiMan - Flexera License Server IP Address and DNS Record
• Unable to upload the controller license file to vSZ/SZ.
• AP license sharing for two controller nodes in cluster
• vSZ: Unable to sync with the license server
• (v)SZ version 3.2 AP support license warning
• URL Filtering Licenses Expire in nn Days - SZ Banner Warning

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

Follow below steps to schedule zone firmware upgrade on vSZ running on 6.1.1.0.x

Login into vSZ GUI>>Administration>>Upgrade >>Schedule Zone Firmware Upgrade

Schedule Task>> “+Create”

Select Specific Zone  for the upgrade

Schedule >> Provide Name/Change Firmware to(Select the version from the available list)/Schedule time( Mandatory fields)
Note : Time will execute at 0/30 min every hour (exp : 1:00, 1:30)

Review all the information before upgrade >> Ok

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

Thank you!

Regards,
Vasanth Edward || Senior TSE
RUCKUS Networks, CommScope!

Customer Environment

Smart Zone 5.2.2.0.1563 or earlier, 6.0.0, 6.1.0 version

Root Cause

Israel DFS channel support was implemented to Smart Zone 6.1.1.0.359 in May of 2022 and have not yet been ported to Smart Zone 5.2.2.0.1563 or older, 6.0.0. or 6.1.0 releases. Future releases of Smart Zone will include Israel DFS channel selection.

Symptoms

Israel DFS channels are missing in Access Point Zones

Workaround

Please upgrade to the following controller + access point patch combination

Resolution

Upgrade to 5.2.2 patch 3 (5.2.2.0.2122) or 6.1.1.0.359 and newer releases to enable Israel DFS channels.

Overview:

There are two types of Signature Packages (Sigpacks) available in the Support site for the v/SZ (virtual SmartZone) platform:

1. Regular Sigpack and

2. Non-Regular Sigpack.

These packages serve different purposes and are designed to be used in specific scenarios.

1. Regular Signature Package:

The Regular Sigpack is a comprehensive package that can be utilized in various scenarios. It is specifically required if you intend to make use of the Client Virtual Id Extraction feature within the WLAN configuration.

• Compatibility: This package is not supported by 802.11ac Wave 1 AP running firmware prior to version 6.0.

2. Non-Regular Signature Package:

The Non-Regular Sigpack is a versatile package designed for use in scenarios other than those requiring the Client Virtual Id Extraction feature. It is compatible with any supported AP model and firmware version.

Note: Using the Non-Regular Sigpack will trigger a prompt indicating that the Regular Sigpack is available for download.

At Application Control > Application Signature Package, users can check the following information:

• Current Signature Package Info:

  • Displays the file name and version of the currently installed package.
  • Indicates whether the current package is the Regular Sigpack.

• Latest Available from Support Site:

  • Displays the latest available Sigpack on the Support site.
  • Indicates whether the Support Regular Sigpack is available for download.

Download here the latest Regular sigpack for 6.1.1

Download here the latest non-Regular sigpack for 6.1.1

Issue noticed: 

Numerous APs experiencing disconnections from control planes and bouncing to different cluster nodes. The frequency of these node changes was notably high, with the same APs observed hopping between nodes every minute and, at times the issue appeared after hours. The issue was very random.

Issue observed in vSZ-H version 6.1.1.0.959.

Checklist:

1. Review the AP event logs to assess the frequency of the issue, focusing on event code 311 (AP changed control plane).
2. Examine the total number of control planes on the Cluster Summary page, observing patterns in AP node changes. Determine whether APs are switching nodes within specific interfaces or across all interfaces in the cluster.
3. Assess the uptime of control planes from the Control Plane section, verifying the accuracy of leader and follower status. Check for recent role changes.
4. Ensure a reasonable balance of APs per node.
5. In the event of a known or recent outage, and if recovery seems inadequate, schedule a maintenance window. Reboot the cluster node to prevent sync issues or any lingering lock-up state.
6. Validate whether uptime aligns with the reboot time after the activity. Confirm that services on all nodes are online and operational.
7. Ensure the vm resources required for the amount of APs involved or connected to the vSZ-H as per configuration guide.
8. Ensure ping reachability, latencies and node to node connectivity between AP to vSZ.

Observed Impact:

The impact can range from minimal to severe, contingent on the total number of APs or APs associated with the cluster node affected. A change in cluster nodes triggers a restart of SSH tunnels, enabling APs to download the updated configuration from the zone. This AP bounce and configuration download can have ramifications for WIFI operation, with the impact escalating significantly when dealing with a larger number of APs.

Logs to confirm:

Observe below logs from the AP support info files;

Sep 14 23:14:05 xxxxxxx-AP daemon.err idm: httpRecv receive fail

Sep 14 23:14:05 xxxxxxx-AP daemon.info rsmd_func[9098]: SSH Tunnel Stopped

Sep 14 23:14:05 xxxxxxx-AP daemon.notice rsmd[45]: sshclient ....... [stopped] (0.686)

Sep 14 23:14:05 xxxxxxx-AP daemon.err rsmd_func[9115]: SSHtunnel: Cannot start SSH-Tunnel. rsm_ip6_sgetSettingsWrapper() function failed to execute. RSM API Return value = 35 : unknown err code 35

Sep 9 00:08:55 xxxxxxx-AP user.err syslog: dbclient - Restarting SSH tunnel due to dbclient restarting itself

Sep 9 00:08:55 xxxxxxx-AP user.info syslog: /usr/bin/dbclient: Connection to sshtunnel@172.25.207.192:22 exited: No auth methods could be used.

From the SZ logs, we observed the error for authorizedKey and the connection status was closed by AP. 

2023-09-27T18:22:18+00:00 vszxxxxx sshd[12236]: error: AuthorizedKeysCommand /usr/bin/sshtunnel_auth_key.sh sshtunnel ssh-rsa 

2023-09-27T18:22:18+00:00 vszxxxxxx sshd[12236]: Connection closed by 10.x.x.x.x port 49404

2023-09-27T18:29:54+00:00 vszxxxxxx sshtunnel_auth_key[29977]: Can not find key ssh-rsa

Based on the aforementioned logs and conditions, a support engineer can decipher the cause of the "Can not find key" error by exploring various combinations. In our specific case, the analysis revealed that a potential trigger for this issue could be a situation where the Command Line Interface to keycached is shorter than the timeout duration set for keycached.

Direction to resolve:

If you observe a similar behavior, please adhere to the checklist below and gather the following information:

1. Follow the provided checklist and include screenshots of any relevant references.
2. Download the AP support info files for a minimum of 2 to 3 APs under scrutiny.
3. Download snapshot logs from both the leader node and the node associated with the identified APs.
4. Initiate a support case, attaching the requested information. The support team will then validate the observed behavior and provide either a KSP or recommend a suitable release to address and resolve the identified issue.

Customer Environment

Any SZ with RUCKUS AI where SZ is behind a firewall and inbound/outbound traffic needs to be allowed for successful communication between SmartZone and RUCKUS AI

Symptoms

SZ is not onboarding/communicating in RA.

Resolution

The endpoints for RA are as follows:

For firewall ports, only outbound 443 needs to be opened from the SZ.

For US

https://ruckus.cloud (34.102.183.44) is used for the administration portal of Ruckus Cloud.

https://messagehub.analytics.ruckus.cloud (34.69.139.151) is used by the SZ to send analytics data to the cloud.

https://serviceloc.ruckuswireless.com (23.236.63.97) is used by the SZ to determine the correct endpoints to connect to. No analytical data will flow to this endpoint but connectivity is required for service discovery.

For EU

https://eu.ruckus.cloud (34.107.197.242) is used for the administration portal of Ruckus Cloud.

https://messagehub.analytics.eu.ruckus.cloud (34.89.193.24) is used by the SZ to send analytics data to the cloud.

https://serviceloc.ruckuswireless.com (23.236.63.97) is used by the SZ to determine the correct endpoints to connect to. No analytical data will flow to this endpoint but connectivity is required for service discovery.

For ASIA

https://asia.ruckus.cloud (35.190.34.117) is used for the administration portal of Ruckus Cloud.

https://messagehub.analytics.asia.ruckus.cloud (34.96.208.196) is used by the SZ to send analytics data to the cloud.

https://serviceloc.ruckuswireless.com (23.236.63.97) is used by the SZ to determine the correct endpoints to connect to. No analytical data will flow to this endpoint but connectivity is required for service discovery.

The above-mentioned IP addresses are subjected to change in future, please use FQDN wherever possible.

If an IP address will change, we will update this content.

Customer Environment
vSZ running on 3.6.2.0.222 loaded in ESXi 6.5

Symptoms
All the APs connected to the vSZ are getting disconnected while migrating vSZ from ESXi 6.5 to 6.7 using vMotion.

Resolution
vMotion is not supported for migration of ESXi as it triggers the S/N of the vSZ change. 

Root cause:
The issue could be due to existing License file on SZ got corrupted. Or
Controller not able to reach to the License server.

Workaround:
Ensure that the controller is able to ping "ruckuswireless.flexnetoperations.com" from controller CLI.
Try using a different browser.
Ensure to use the right license file.

Solution:
We have to delete the existing license file using the command and then re-sync the license details. This should resolve the issue.

vSZ#config
vSZ(config)#license cloud enable
Are you sure you want to change the license server configuration? All current license data will be wipe out!! (or input 'no' to cancel)? [yes/no] yes
Successful operation
vSZ(config)#license sync-now

Microsoft AD User Group setting.

From Microsoft AD open Administrative Tools>>>Active Directory Users and Computer.
User Group Mapping

In Active Directory Users and Computer select the group which needs to allowed for Guestpass generation and Map Members to it with the Add button.

e.g.
GPASS is the Group as below.
vijayguest is the member mapped to it.

How to find right DN pattern (Group and User)

Open command Prompt and run below command one by one.

("dsquery group -name <groupname>")
("dsquery group -name <username>")

<groupname> is variable "GPASS" as in below example

<username> is variable "Administrator" as in below example

This DN pattern will be used in the AAA server setting for Search filter and Administrator Domain.

Administrator

Create an administrator user on SZ/vSZ GUI>>>Administration>>>Admin and Roles>>>Administrator

(guestpassuser for example, this is a dummy user).

Groups

Create an Group on SZ/vSZ GUI>>>Administration>>>Admin and Roles>>>Groups

With below settingas example.

Permission

Resources

Administrator

Move user to the right with the arrow to map to the group.

Review

Review the setting and click OK.

AAA

Create an AAA LDAP server on SZ/vSZ GUI>>>Administration>>>Admin and Roles>>>AAA


Turn on Default Role Mapping
Select User Groupcreated as above(GPASS)
Select Administrator created as above(guestpassuser)
Select LDAP from the checkbox
Fill Realm as AD domain (wireless.com for example)

IP address of Server and Port number (389 for LDAP)
Base Doamin(exact domain) and Admin Domain based on ds query for Administrator.
Type LDAP Administrator password and Confirm password.
Fill Key Attribute: "cn"

Search filter

Search Filter in the below format and Click OK to Save.(based on the dsquesy results, max character limit in the box is 64)

(objectClass=*)(memberof=CN=GPASS,CN=Users,DC=wireless,DC=com)

Test AAA Server

AD User part of GPASS group will pass authentication.

AD User not a member of GPASS group will fail to authenticate.

Once tested verify login from the admin page as well.

LDAP User group authentication will succeed (GPASS in this example).

Authentication will fail for non LDAP Group User (GPASS in this example).

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.

I am going to deploy the vSZ into our infrastructure. I have successfully deployed the OVA template to our VMWare. When it asks to configure the network interfaces, it shows three network interfaces. Should I go ahead to deploy 1 network interface or 3 network interfaces? Or any other options? Any paticular idea on what should I go for?

Here is some of the background of our network. 

- most of our staffs and guests are in the centralized office
- some are in remote offices, but they are all connected directly back to our main office, different subnet but all routable
- we would like to deploy at least 6 SSIDs where 1 of them is for the guest access
- going to deploy 30 units of APs

Happy to get the idea from anyone.

Tim

It’s optional but recommended to update this file to the appropriate version of the newly installed version. Verify the RUCKUS v/SZ Upgrade Guide to learn more about this. 

Is the upgrade of the sigpack failing? Just skip this task and attempt the upgrade after the controller is on the newer version.

- - 

Orlando Elias /Support team

For input string: "9210"

After restarting our virtual machine I can see our AP's for a few minutes again, but then the same error occurs.

These are our System Infos:

Controller Version: 6.1.0.0.935
Controll Panel Software Version: 6.1.0.0.683
AP Firmware Version: 6.1.0.0.159

Thanks in Advance!

Requirements:

• A computer with Wireshark installed (wired or wirelessly connected to the network)
• Access to the affected AP's IP address
• Access to the SmartZone's web user interface

Procedure:

1. Start the Capture on the AP:

• Access the SmartZone's web user interface.
• Navigate to the specific AP for which you want to capture packets.
• In the AP settings, find the option to initiate a packet capture on the AP radio.

• Start the packet capture from the AP radio. Ensure that it captures data from all traffic types simultaneously. (Management, Control and Data)

2. Prepare Your Computer:

• Ensure that Wireshark is installed on your computer.
• Launch Wireshark.
• Before starting the capture, navigate to Capture > Options.

• In the 'Capture Options' window, click 'Manage Interfaces'.

• In the 'Manage Interfaces' window, go to the 'Remote Interfaces' tab.
• Click the '+' icon to add a new remote interface.

• Type the IP address of the affected AP in the 'Host' field.
• Leave the 'Port' field blank.
• Select 'Null authentication' from the dropdown menu.
• Click 'OK'.

3. Select All Interfaces:

• Back in the 'Manage Interfaces' window, all interfaces of the affected AP will be listed and checked. Ensure they are all selected or just select the interfaces you know you need to capture from.
• Click 'OK'.

4. Prepare for Capture:

• Be ready with a testing device in the affected area before proceeding, as you will start receiving a significant amount of traffic.
• Select the specific interfaces you will be capturing on this round. For this demo I will be selecting wlan32 and br0 (br0 is a virtual interface that bridges all other interfaces together).
• Click 'Start' in Wireshark to begin capturing traffic from the selected interfaces.

**Note: Avoid capturing traffic from ALL the interfaces at the same time as this may cause performance degradation on the AP or it could crash the resources of system hosting the Wireshark application.

**Note: In order to find out the WLAN number of your WLAN of interest, we must run from the AP CLI the command 'get wlanlist'. Note that there is a WLAN number for 2.4 GHz SSIDs and a different WLAN number for 5 GHz SSIDs (wlan0 to wlan7 for 2.4 GHz, wlan32 to wlan39 for 5GHz):

5. Perform the required testing:

• Conduct the testing required to replicate the issue. Make sure the issue is replicated while the packet collection is performed.
• Note that Wireshark will tell you the interface where the packet has been collected from:

• Once the testing is completed, stop the capture in Wireshark.
• Save the captured data in Wireshark to a file for further analysis. (If the captured that is too much, filter the desired packets and save only the portion of interest) 

• Access the GUI of the AP and stop the capture from there.

Collect the Support Log:

• Collect the support log of the AP. This log may contain valuable information for diagnosing the issue.

By following this procedure, you can initiate a packet capture from the AP radio using the SmartZone's web user interface and gather packet captures from all interfaces of the AP, which can be invaluable for troubleshooting and resolving wireless connectivity issues.

This AP patch will not affect the firmware in the controller and no reboot of the controller is required.

A downtime must be programmed as the APs will reboot once the get their new firmware. The estimated downtime will be maximum 5 minutes per AP.

Go to Administration, Upgrade and AP Patch: (You will be able to see the AP Patch Histroy and find out if the patch has been already installed and when it happened)

Upload the desired .patch file:

You can check the file details one more time before finally applying the patch to the controller. (This action will not trigger any upgrade to any AP, the AP firmware upgrade still need to be manually triggered)

When the apply process is completed, you will be logged out of the we GUI. Login one more time to perform the AP firmware upgrade to the desired AP Zones or just leave for a later time.

To finally upgrade the AP firmare in the APs, go to Access Points, select the AP Zone, click 'More' and 'Change AP Firmware'. 

Select the desired AP firmware version. The APs will receive the new firmware and reboot.

Can we upload 3.6.2.X AP Zone firmware on SZ-144 running 5.2.2.X or 6.1.1.X