Subject: [Ruckus-Unleashed@192.168.xxx.xxx] Alarm 'SSID-spoofing AP Detected' generated
"An alarm 'SSID-spoofing AP Detected' was triggered."

What would be the best practice for checking what triggered this alert? Can you recommend what things we need to look at? Thank you!

What is the best practice to to keep traffic from my IoT devices which are capable of connecting to 5GHz away from my main network?

Actually my question is a little bit more involved. Years ago, I separated my 2.4 GHz and 5GHz bands on my R550 at home. This is what my home network looks like currently:

IoT SSID is 2.4 GHz only and on VLAN 2
Home SSID is 5 GHz only and on VLAN 1
Guest SSID (Rucks handles it)
Side business SSID for members on VLAN 3

VLAN 2 & 3 have no ports open to VLAN 1. I have a router - Firewalla Purple which handles those rules.

Everything works "almost" fine but many times while using the microwave in the kitchen the Amazon echo and firesticks disconnect. They are on the IoT network (as they should) but the microwave interferes with 2.4. The devices on 5 keep on working fine. These Amazon devices "are" fully capable of using 5.

So what I am wondering is this:

Should I create a third SSID - IoT2 for VLAN 2 and have 5GHz on it? Or should I go old school and enable both 2.4 & 5 bands on the existing IoT SSID. I am afraid that all the plug-in switches, receptacles, lights and crappy old IoT devices which are strictly 2.4 GHz only and use that IoT SSID will then have connectivity issues.

I do want (eventually) the Amazon devices to be able to use my home server (via Plex) and show photos and movies stored there. But that is a firewall config thing, which I can handle on my router (Firewalla Purple). But that is why I was thinking: Why not put the Amazon devices on the home network. Are they "that insecure"? I mean, I am sure I would keep the crappy no name IoT switched-sockets & bulbs totally separate but..... ummm..not sure about the Amazon devices.

What do others do?

Your suggestions are most welcome!

Thanks

For devices running FastIron release 09.0.10a to 09.0.10h, attempting to establish an SSH connection with a device running FastIron release 08.0.95 or earlier can lead to a mismatch in algorithms, preventing the SSH connection from being established. This problem occurs during the negotiation phase, where the server offers key exchange and host key algorithms that are not compatible with the default settings of the device running FastIron release 09.0.10a to 09.0.10h.

For devices running FastIron release 09.0.10j and later, RUCKUS recommends configuring specific key exchange and host key algorithms on the devices to resolve this issue and enable SSH communication. Please follow the procedure below to enable SSH communication with devices running FastIron release 08.0.95 or earlier:

device# configure terminal
device(config)# ip ssh key-exchange-method
ASCII string Enter algorithms separated by a space:
             diffie-hellman-group-exchange-sha256
             diffie-hellman-group14-sha256
             diffie-hellman-group16-sha512
             diffie-hellman-group18-sha512
             curve25519-sha256@libssh.org
             diffie-hellman-group14-sha1
             ecdh-sha2-nistp256
             ecdh-sha2-nistp384
             ecdh-sha2-nistp521
             curve25519-sha256
device(config)# ip ssh key-exchange-method diffie-hellman-group14-sha1
device(config)# ip ssh host
   host-key-method                 SSH host key method
device(config)# ip ssh host-key-method
ASCII string Enter algorithms separated by a space:
             ecdsa-sha2-nistp256
             ecdsa-sha2-nistp384
             rsa-sha2-512
             rsa-sha2-256
             ssh-rsa
device(config)# ip ssh host-key-method ssh-rsa

1. You must access the switch via console.
2. Press Ctrl + Y.
3. Enter "reset_login"
4. Exit the console.
5. Try logging in using the default credentials: username "super" and password "sp-admin."

OS> reset_login
This is a temporary login. Please reconfigure users once you login.
OS> exit

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!

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.

Just for an update about the upgrade path process when upgrading from older software versions. Based on these documents 

https://docs.commscope.com/bundle/fastiron-09010-upgradeguide/page/GUID-7894E17A-26A1-4094-BE3A-279649D8E05B.html

https://docs.commscope.com/bundle/fastiron-08090-upgradeguide/page/GUID-5DD7EE86-6988-4CA7-81D2-22EA77BD1992.html

https://docs.commscope.com/bundle/fastiron-08095-upgradeguide/page/GUID-5DD7EE86-6988-4CA7-81D2-22EA77BD1992.html

The upgrade process is this one

"The upgrade path is 08.0.70 or prior -> 08.0.80f (non-UFI) –> target release (UFI)”

So the correct upgrade process is this one “08.0.70 or prior -> 08.0.80f (non-UFI) –> target release (UFI)”

Of course, there are some scenarios where it may change a bit like this one:

Note: If you are upgrading an ICX switch for the first time from a version earlier than FastIron 08.0.95, RUCKUS recommends that you upgrade to FastIron 08.0.95d as the intermediate version and then upgrade to FastIron 09.0.10a or later. This step is required to ensure that the FPGA version is compatible with the target release.

This is an important security announcement.

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

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

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

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

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

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

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

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

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

Some quick facts:

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

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

Thank you!

Experienced a brief power outage today, 4/24, around 3:45 PM PDT. Since then the RUCKUS switch (ICX7150-C12P) has been unable to reboot. APs are also down without any lights.

I attempted to perform a software recovery by following the instructions closely from the following post/URL: RUCKUS Forums - How to perform a Software recovery on an ICX7150 s... - CommScope RUCKUS Community Forums (ruckuswireless.com)

When I reached the step to ping 192.168.0.2, I received a "ping failed; host 192.168.0.2 is not alive." I went back and double-checked each step to ensure I did not make a mistake. I also tried using different equipment (laptop/desktop, ethernet cable, etc.) but to no success.

PuTTY terminal

In researching my issue, I was able to find another community's member's post below and it appears I am running into the same issue and that a possible RMA may be required.

URL: Solved: RUCKUS Forums - ICX7150 stuck in boot mode - "is not alive" when t... - CommScope RUCKUS Community Forums (ruckuswireless.com)

Here are some additional photos of the setup:

Laptop - Red USB-A to USB-C cable (connecting to Switch) and Ethernet port and yellow ethernet cable (connecting to Management Port on Switch)Overall - Laptop & SwitchSwitch - Red USB-A to USB-C cable connecting to console and yellow ethernet cable connected to Management Port

Please advise.

Note: The USB flash drive must be formatted in FAT32 and should be a Standard Type-A USB. 

For detailed instructions on how to format the drive on Windows and macOS systems, please refer to the following guide: 

Ensure the USB drive is formatted to FAT32 and is a standard USB.

Steps to upgrade: 

A. Initial version upgrade: 

When upgrading from a non-UFI version, we must first upgrade to the initial version (08.0.80f) before proceeding to the recommended version (08.0.95g). 

The Upgrade path would be: Non-UFI version before 08.0.80f version>>08.0.80f>>08.0.95g 

1. Download and extract/unzip the initial version 08.0.80f 

Figure 1: Download path for the initial version 

Figure 2: Accepting the download agreement

2. Navigate to the ICX 7150 > Boot directory and copy the mnz10114.bin file. 

Figure 3: Downloading the boot file 

3. Navigate to the ICX 7150>Images folder and copy SPS08080f.bin 

Figure 4: Copy the initial version image 

B. Download 08.0.95g version images:

1. Log in to the RUCKUS Support Downloads page . 

2. Select RUCKUS ICX7150 Campus Switches from the ‘Choose A Product’ menu.  

Figure 5: Download path for recommended version 

3. Select 08.0 from the Version menu. 

Figure 6: Choosing Download version

4. Select RUCKUS ICX FastIron 08.0.95g (GA) Software Release (.zip). 

5. Click Download software.  

Figure 7: Downloading the recommended 08.0.95g version 

Figure 8: Accepting the Download agreement 

6. Unzip the downloaded file and extract all contents. 

7. Navigate to the ICX 7150 > Images folder and copy SPS08095gufi.bin and paste in the same folder we created previously.

Figure 9: Copying the download image 08.0.95g version 

8. Create a new folder named Upgrade and copy the following files into it: mnz10114.bin, SPS08080f.bin, and SPS08095gufi.bin.

Figure 10: Copying the downloaded images 

C.   Connect the USB drive to the RUCKUS ICX-7150 Switch 

Insert the USB drive into the designated USB port on the ICX-7150 switch. (Figure 11)

Figure 11: Physical USB Port 

D. Accessing the Switch 

1. Connect to the switch using SSH, Telnet, or a console connection. 

2. Enter the 'enable’ command to switch to User EXEC mode: 

Figure 12: Accessing the Switch CLI 

E.   Verify USB Recognition 

1. Use the 'mount disk0' command to ensure the Switch recognizes the USB.

Figure 13: Switch recognizing the USB 

2. Use the 'show files disk0' command to view the contents of the USB drive.

Figure 14: Viewing the contents of USB

F. Upgrade to Intermediate version 

Note: The switch has two flash storage partitions, Primary and Secondary. 

• 'show flash' command will show the codes installed on both partitions of the switch. 

Figure 15: Display codes on both partitions 

• 'show version' command will display the actual version on the switch.  

Figure 16: Display Switch version 

1. Upgrade the bootrom using the command “copy disk0 flash mnz10114.bin bootrom” 

Figure 17: Copying the Initial version boot file 

2. Upgrade to intermediate version 8080f using the command “copy disk0 flash SPS08080f.bin secondary” (Can install in both primary and secondary partitions) 

Figure 18: Copying initial version image 

3.Use the command "show flash" to check if it was installed correctly in the right partition. 

Figure 19: Check if version was installed 

4. Use the command “boot system flash secondary yes” to boot the Switch from the secondary partition to make sure the image was installed correctly.

Figure 20: Boot Switch from Secondary partition

5. Use the 'show version' command to check the current version once the boot process is complete and the version should be 08.0.80f 

Figure 21: Checking the current Switch version 

G.   Upgrade to recommended version 

1. Use the command “copy disk0 flash SPS08095gufi.bin secondary” to copy from intermediate 08.0.80f to recommended version 08.0.95g. 

Figure 22: Copying recommended version image 

2. Use the command “boot system flash secondary yes” to boot from the secondary partition once the copy is complete. 

Figure 23: Boot System from secondary partition 

3. Use the 'show version' command to check the current version once the boot process is complete and the version should be 08.0.95g 

Figure 24: Checking the Switch version 

H. Synchronize the partitions: 

For best results, we recommend having both partitions on the same version.  

1. Use the command “copy flash flash primary” to re-flash from Secondary to Primary. 

Figure 25: Copying same image on partitions 

2. Use the command “show flash” to confirm the copy. 

Figure 26: Checking the Switch version after upgrade 

The RUCKUS ICX-7150-C12P Switch is now upgraded to the recommended version 08.0.95g. 

User/admin query?

How much time a service will take to come back, when a new certificate is mapped with SZ services?

Customer is renewing controller's wildcard CA cert as it is expiring soon (new cert has same domain name so just validity will change). They want to know below details to make sure there is no or minimum service impact:

Customer general FAQ with answers

1. What will be the service impact for each service and end clients which are already connected or may connect during service cert change.

Answer:

Notes:

• No impact to existing clients but client connecting during the service restart may face issues on captive portal/guest SSIDs.
• Admins using the SZ GUI may get certificate error or may not at all able to access SZ UI during service restart (web is one of the services which will restart, post applying the new certificate).

2. How much time it will take for service to come to normal after changing all 4 certs to service mapping and hit OK?

Answer:

Certificate update/install will restart subscriber mgmt, NBI and Web services. Customer can upload all these certificate at once and you can assume roughly 15 minutes (max) of downtime for services to recover

3. Do we need downtime if there is possibility for client disconnection or service impact?

Answer:

Usually no downtime required for client connection but to avoid captive portal certificate errors, its better to update certificate during a maintenance window so that users will not wonder why they are getting certificate error.

4. How to check service status?

Answer:

Go to SZ CLI >> Enable mode >> run "show service"

Got additional questions or need help? Start the conversation!