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

Kindly assist. 

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

How can I tell if the retransmission rate is high?

• From the AP support log. 

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

Excessive retries can be directly related to PHY errors:

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

• From Wireshark.

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

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

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

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

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

wlan.fc.retry == 1

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

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

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

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

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

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

PWR (Power Indicator):

Solid RED: Bootup in progress.

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

Solid Green: Routable IP address received.

CTL/DIR (Control/Direction Indicator):

Off: AP is a RUCKUS Unleashed member AP.

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

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

Solid Green: AP is the RUCKUS Unleashed Master.

AIR (Mesh indicator:)

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

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

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

Blinking Solid Green (0.5 Hz):         

2.4G (WLAN Service Indicator):

Off: The WLAN service is down.

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

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

5G (WLAN Service and Mesh Downlink Indicator):

Off: The WLAN service is down.

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

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

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

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

1. Client Connection Troubleshooting

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

This is a demonstration for the client troubleshooting.

Select Clients, and then click the Troubleshooting button.

Figure 1: Clients Tab

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

Figure 2: Troubleshooting button.

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

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

Click the Start button to begin the troubleshooting.

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

Figure 3: Start Troubleshooting Process

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

Figure 4: Troubleshooting Process

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

Figure 5: Initial Packet Capture View

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

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

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

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

Figure 7: Final Analysis - Client Failed Handshake

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

2.    Capturing Remote Packets

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

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

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

Figure 8: Packet capture tab

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

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

Figure 9: Selecting the Access Point for the Packet Capture

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

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

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

In this example we are going to select Local Mode.

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

Figure 10: Initiate the Packet Capture

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

Figure 11 : Downloaded PCAP from the Unlashed UI.

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

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

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

Unleashed Overview

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

Unleashed Support

-Bridge mode 128 APs and 2,048 clients.

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

-Dedicated Master

Overview Limitations from Zone Director

-IPv6 is not supported.

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

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

-No WLAN groups.

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

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

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

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

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

The same information can be collected on the Master AP.

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

Ruckus CLI on unleashed when SSH to the Access Points.

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

Enable:

ruckus#

Under enable mode we can go to different modes example:

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

ruckus(ap-mode)#

Config

ruckus(config)#

Under config there are some different modes

+Admin:

ruckus(config-admin)#

+System:

ruckus(config-sys)#

+Using the Mac-address of the AP: 

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

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

Best Regards 

Fernando Vasquez 

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

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

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

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

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

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

7-Configure the “Connection Request Policies”

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

8-Configure Network policies

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

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

Optional step

How to create a group and users

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

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

How to create an user

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

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

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

9-Unleashed Configuration

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

10- WLAN Creation

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

11-Wireless Client

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

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

RUCKUS vendor code:

- 06 for SmartZone

- 03 for Zone Director

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

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

How did they get to such a result? 

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

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

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

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

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

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

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

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

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

Example for the IP address "192.168.0.200":

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

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

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

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

Anyone know a way to import the CSVs?

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

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

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

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

Number of devices it can deliver PoE to.  

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

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

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

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

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

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

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

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

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

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

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

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

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

General information to request:

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

https://support.ruckuswireless.com/software 

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

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

Customer Environment

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

Symptoms

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

Resolution

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

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

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

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

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

Network Requirements

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

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

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

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

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:

Greetings from RUCKUS!

We’re glad to have you here! To make your experience smoother, we’ve created the RUCKUS Lennar Knowledge Base, a dedicated self-help section with step-by-step guides, solutions to common issues, and troubleshooting resources for your RUCKUS devices.

Before posting a new question, we kindly encourage you to:

1. Visit the RUCKUS Knowledge Base to check if your issue is already addressed.

2. Use the search bar or browse related content links to see if other users have discussed the same issue.

3. Join existing discussions where you can find valuable insights or share your experience.

If you don’t find a solution, please post your query in the RUCKUS Lennar Support section, and our team will be happy to assist you in resolving issues with your Lennar Home RUCKUS devices.

Thank you for being part of the RUCKUS Lennar Community, your contributions help make this space a richer resource for everyone!

As compared to Unleashed bridge mode, the following features are supported in Dedicated Master mode:

• Cross-network segment networking
• Dedicated Master VLAN and AP VLAN
• Smart Redundancy
• Maximum capacity limit to 4,000 clients (compared to Unleashed bridge mode)
• Tunnel WLAN
• ZoneDirector AP migration to Unleashed network

To disable dedicated master a factory reset must be done.

Is important to highlight that this is different from setting a preferred master, as this setting is not bounded to an ap model, any other Ethernet-connected member AP can take the Master role. For more info on preferred master please visit Designating a Preferred Master AP

We can see that even when the enable port is checked, we are unable to update the VLAN untagged ID on the cloud GUI.

Many customers have inquired about the inability of a certain AP model, such as the R350, to modify the untagged VLAN ID on the cloud.

This is the design objective for a single LAN port APs, as there is no VLAN given in the ethernet frame for untagged traffic.

For example, our AP on VLAN 1 will be able to communicate with any other side device on any untagged VLAN.

Any changes to the AP for the untagged VLAN ID that are necessary to get the AP onto the chosen subnet must be made at the switch port level where AP is connected.

I hope you find this information useful.

• Make sure that all switches and APs added on cloud should be operational.
• Make sure to whitelist below IPs/FQDNs on your firewall outbound rules:

1.            IP range: 34.87.82.64 through 34.87.82.95, ports: tcp 443 & 22
2.            FQDN: ap-registrar.ruckuswireless.com, port: tcp 443
3.            FQDN: sw-registrar.ruckuswireless.com, port: tcp 443
4.            FQDN: ocsp.comodoca.com, port: tcp 443 & 80
5.            FQDN: ocsp.entrust.net, port: tcp 443 & 80
6.            FQDN: device.asia.ruckus.cloud, port: tcp 443 & 22
7.            FQDN: storage.googleapis.com, port: tcp 443

Post migration connectivity checkpoints and troubleshooting before contacting Ruckus Support:

AP Troubleshooting:

• Connect laptop to a switch and same subnet as APs. Ping device.asia.ruckus.cloud, and please check if the resolved IP is in range: 34.87.82.64 through 34.87.82.95.

• If the resolved IP is outside the mentioned range (34.87.82.64 through 34.87.82.95), make sure to flush DNS cached entries from DNS server. Now try to resolve “device.asia.ruckus.cloud” and validate that IP resolution is within the specified IP range.

$ curl -XGET “https://device.asia.ruckus.cloud”

On MacOS, a success response would be:

curl: (56) LibreSSL SSL_read: LibreSSL/3.3.6: error:1404C45C:SSL routines:ST_OK:reason(1116), errno 0

On Windows PC, a success response would be:

     curl : (56) Send Failure: Connection was aborted

• Check reachability to https://device.asia.ruckus.cloud using the command below.

• Feel free to contact Ruckus Support, if all the troubleshooting steps are exhausted.

ICX Switch Troubleshooting:

• For Switches on version 9010e and 9010f kindly reboot the switches to clear DNS cached entries.

• Switches on version 9.0.10h_cd2 and 10.0.10b (for ICX 8200 switches) will not require a reboot to get connected to the new DC.

• Run “show sz status” from switch CLI and check SWR (Switch Registrar) IP has updated new IP range from 34.87.82.64 through 34.87.82.95.

• If the IP address is outside the above range run below commands:

1. device(config)# manager disable
2. device(config)# no manager disable
3. device# manager registrar-query-restart
4. device# show manager status

• Feel free to contact Ruckus support if above steps does not help.

Note that, switch disconnection from cloud doesn’t impact the production due to data center migration.

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.

— Requirements:

*SSH client access (Putty on Windows, macOS command Terminal, or Linux terminal).

*Download putty for Windows computer.

https://putty.org/

*For macOS, you will use the terminal app integrated into your MAC.

Enter the next command from the MAC terminal for SSH access

Format

ssh <unleashed user>@<IP of the master Access Point>

Example

ssh admin@192.168.1.1

*Or from Windows open Putty and add the next information, then hit open

Note: the credentials for the CLI access to the master Access Point are the same credentials you used for the APP or the Web GUI

1: Using your SSH client application such as a putty or MAC terminal, gain access via CLI to the AP Master Unleashed.

2: Now enter the credentials:

Note: the credentials for the CLI access to the master Access Point are the same credentials you used for the APP or the Web GUI

Enter the username and password

You should be at the command prompt 

Enter the username and password

You should be at the command prompt 

ruckus>

Enter the following command: enable

ruckus>enable

ruckus#

Enter the command: config

ruckus#config

ruckus(config)#

Enter the command: show wlan

ruckus(config)#show wlan

Enter the command: wlan home-WiFi

Replace home-WiFi with the name of your Wi-Fi SSID

ruckus(config)# wlan home-WiFi

ruckus(config-wlan)#

Enter the command: no qos directed-multicast

ruckus(config-wlan)# no qos directed-multicast

Enter the command: qos directed-threshold 0

ruckus(config-wlan)# qos directed-threshold 0

Enter the command: end

ruckus(config-wlan)# end

This will save the changes.

Now restart your SONOS components

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

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.

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.

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.

Given that in a deployment, we see various devices from various vendors. The scope of the article is written with troubleshooting and isolation procedures in hand with vendor neutrality.  

When there is a report of slowness of traffic, isolation is needed as in:

• Is the latency on the traffic bound towards the internet.
• Is the latency on the local site traffic.

1> If the latency is seen:

When accessing data or application hosted remotely on a cloud server or on another site
When connecting to the internet and web pages load slowly

This would be external to the network.

Here for this,
Step by step elimination is needed, to know at what point the latency is coming up and is being seen.

in this scenario: it would generally appear on/above core switch level moving towards the internet connection [ISP’s CPE].

And the BW provided by the ISP can also contribute to this, if in case there is a large resource dependency on the remotely hosted data for the user base.

Gauging this can be done using:

• Remotely hosted Iperf server [ there are a few that are available publicly  Click here ]
  This can help with BW assessment.

• https://speed.cloudflare.com/ : this can help gauging the ISP connection for latency
  As this gives detailed statistical output of :
  Packet Loss measurement
  Latency measurements
  Jitter
  Download and upload measurements.
  Including uplink and downlink speeds on the connection.

2> If the latency is seen:

When accessing data or application hosted locally on site
When connecting to the application or servers the data loads slowly.

Note :

"When connecting to the application or servers the data loads slowly." Here, the given condition is :
That the servers or the set of servers are not burdened with many concurrent users
And the servers in the set up are having the specifications to handle a given user load and function well under load.

This would be internal to the network.

Here the isolation would need to be followed in the below manner:

• Are the user and the resource that’s being connected to located in the same subnet or across subnet:
• If in the same subnet:
• then would also need to check if there is any trouble on the end points.
• Would need to check if there are or is any traffic suppression going on. : like excessive broadcast and more.

• If across subnets:
• First check for traffic suppression and/or redirection
  Redirection at times can happen when working across north-south bound traffic.

• During what operation is the latency seen, to name a few:
  During a file transfer
  During remote access/RDP session
  During video conferencing / VoIP calls

This would help us identify the type and nature of traffic getting impacted.

• If during Data transfer / file transfer:

In this case: check if there is any resource usage and or frame loss being seen during operation.
If the above, comes clean and yet it’s still seen check the traffic flow pattern.
traffic suppression and/or redirection, this can cause there to be re-transmits to be seen, usually they are the tell-tale indicators here.
Once this pattern is seen and established, appropriate measures are needed to be employed.

• If during remote access or RDP session:
• This is here is a example of application specific concern

Here if there are multiple users/RDP sessions in progress: there is a chance you can see the disconnections/timeouts/interruptions/drops etc.

And on the LAN devices you will see drop counters increment on the interface.
More specifically interface queues.
Usually seen on Q0 as this where all default traffic would go.
RDP traffic by default will be processed/traversed here on Q0

On this case as this comes downs to specific queue:

You can try having the minimum guaranteed bandwidth set for the interface queue: this should re-allocate buffer bandwidth to necessary queues.
This option is provided by most vendors: here's ours  

If that does not help, then QoS re-marking would be the other effective option for the traffic prioritization over the network.

• If during video conferencing /VoIP calls:
• This is here is an example of traffic specific concern

Here it would more towards on the network: with VoIP networks usually QoS is already in place.

Hence, it’s can possibly be a rare event for the VoIP Network to have that.

However, Video conferencing applications like Teams and Zoom this can happen.

For here traditional QoS settings may work to an extent …... But not completely

As this would be application traffic.

Hence here we explore two options: to make effective use of the underlying LAN's QoS /CoS features.

1> easy way approach: have the application mark the DSCP on the exiting traffic.
Zoom has this option: and with Admin Privilege that can enabled for the organization.
click here 

Once this traffic is marked: have the network trust it : this will ensure the traffic receiving proper priority when being forwarded across the network.

2> Network based approach:

Here the application will not have a feature to mark the traffic.
However, there will be a set of TCP/UDP ports that the application uses for each task
Teams we have this bit when it uses a certain range of TCP/UDP ports for
Audio, Video and content sharing 
click here 
Based on this: on the network where all traffic converges : usually at the core
Have a L3 QoS DSCP policy set marking the respective traffic based on these ports.
And have rest of the network devices: trust the data stream coming from the core.

Other important bits that can help identify latency:
After the above isolation is done: to understand whether the latency seen is external or internal in nature. 
Below are a few Ways to find out if latency turning up in the network.

• Ping stats:

ping 1.1.1.1 -n 10

Pinging 1.1.1.1 with 32 bytes of data:

Reply from 1.1.1.1: bytes=32 time=46ms TTL=56

Reply from 1.1.1.1: bytes=32 time=47ms TTL=56

Reply from 1.1.1.1: bytes=32 time=46ms TTL=56

Reply from 1.1.1.1: bytes=32 time=47ms TTL=56

Reply from 1.1.1.1: bytes=32 time=44ms TTL=56

Reply from 1.1.1.1: bytes=32 time=45ms TTL=56

Reply from 1.1.1.1: bytes=32 time=44ms TTL=56

Reply from 1.1.1.1: bytes=32 time=52ms TTL=56

Reply from 1.1.1.1: bytes=32 time=143ms TTL=56

Reply from 1.1.1.1: bytes=32 time=50ms TTL=56

Ping statistics for 1.1.1.1:

    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 44ms, Maximum = 143ms, Average = 56ms

Here in a sample space of ten pings:

the highest response time outlier seen is at 143ms.

the lowest response time outlier seen is at 44ms.

the sample space is seen to average out at 56ms.

Here the things to look out for: lowest/minimum response time and average response time.

This should not be high: if the same or either are high then the same does indicate there is latency.

As highest that we see is selected from the highest of all data points.

As lowest that we see is selected from the lowest of all data points.

Hence the lowest would be a better measure.

NOTE:
Its suggested that Ping should be done from host to host and not from a switch/AP/Router or to a switch/AP/Router for detection of latency as switch/AP/Router process pings differently.
Ping can be used to check if the device is responding or not. 

• Iperf Test:

This helps gauge the BW seen by the end client through the network.
Also gives a fair understanding of whether the traffic traversing a specific direction faces any choke points.

Here once this is done checking path link by link would also help: as BW between two end points can be impacted by the BW of the interconnecting links as well including the device itself.

• Network assessment:

This would encompass the checking of redirection based issues, retransmits.
Traffic suppression, impact due to broadcast storms and loops [ physical and logical] etc.

Abbrevations : 
ISP > Internet Service Provider 
CPE > Customer Premises Equipment 

To disable status LEDs on all APs of a specific model:

1. Go to Access Points > Summary > Edit > Other.
2. Select the AP model from the list and enable the option Disable Status LEDs. The setting must be configured for each AP model individually.
3. Click Finish to save your changes

For more info on the LED behavior meaning please visit: https://community.ruckuswireless.com/t5/RUCKUS-Self-Help/Ruckus-AP-LED-indicator-meaning/td-p/67848

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

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.

There are different type of Ruckus Access points and majorly categorized in below categories.

Indoor APs.

• RXX0 series (Standard Indoor)
• HXX0 series (Wall-Mounted)
• MXX0 series (Mobile Indoor)
• CXX0 series (Cable modem - Indoor Wall Mounted)
• ZoneFlex or ZFXXXX series (EOL)

Outdoor APs

• TXX0 series (Standard Outdoor)
• TXX0 series CM (Outdoor - Cable modem)
• EXX0 Series (Embedded)
• ZoneFlex or ZFXXXX series (EOL)

Note: Here XX0 stands for first two digits of different AP model numbers, like 310, 510, 610, 710, etc.

Reset/FD (factory default) physical button location for Indoor APs.

R series

In R series Ruckus has many different AP models and though physical layout may look different for each AP, reset button is always located near the ethernet port or in some APs near the USB port.
One thing to note, in R series APs there will be single Reset button. Pushing the button just once and releasing it will do a restart (power cycle). Pushing and holding the button for 8 seconds or more will factory default the AP settings.

H series

In H series APs you will find two separate buttons. One for "Reset" (Reboot the AP) and other for Factory Default (FD).

M series

C series (Cable modem Indoor Wall Mounted)

ZoneFlex (ZF) series (EOL)

All (most) older RUCKUS access points models starts with ZF has the similar physical layout as the newer access points. Just identify the type of your AP (Indoor, outdoor, Wall mounted, etc) and refer the same information given for new AP models.

Reset/FD (factory default) physical button location for Outdoor APs

T series (Standard Outdoor)

You can reset the AP factory default settings by pressing the reset button behind the access plug covering the Ethernet port (PoE IN port).

Note: Your AP layout may look different but reset button is always hidden inside the PoE IN plug covering the Ethernet port for all Ruckus outdoor APs.

T series CM (Outdoor - Cable modem)

E Series (Embedded)

Note: Remember to replace the Torx screw covering the Reset button after use. Insert the screw and torque to 4 in-lbs.

ZoneFlex (ZF) series (EOL)

All (most) older RUCKUS access points models starts with ZF has the similar physical layout as the newer access point. Just identify the type of your AP (Indoor, outdoor, Wall mounted, etc) and refer the same information give for new AP models.

Procedure for physical factory reset or hard reset.

1. Identify the type of AP model from the above list.
2. Find a paper clip or the clip which came with your RUCKUS AP.
3. Make sure AP is power ON while you perform reset.
4. To factory reset, locate the Reset (FD button for Wall Mount APs).
5. Push the button with clip and hold it for 10 seconds (8 seconds are required but to make sure reset is done correctly, use 10 seconds).
6. Release button and let the AP factory reset and boot.

Procedure to factory reset the AP using AP CLI

1. Locate the AP IP address
2. Use a terminal application like Putty and SSH into the AP IP address
3. Type the AP's CLI admin username and password (this depends upon how AP is being managed)
   • For ZoneDirector managed APs username password will be the same as Zone Director admin credentials.
   • For Unleashed also it will be the same as your Unleashed master AP.
   • For SmartZone managed APs it will be the user name password set in AP Zone's settings.
   • In default state AP's default user name and password is: super/sp-admin
4. Now run the commands "set factory" followed by "reboot".

Note: APs managed by Ruckus Cloud cannot be factory default using CLI. Either you have to do using Cloud UI or using physical button.