Ruckus Wireless as an Unifi alternative?

[Infinite]

Depending on the firmware that you are running, you could also simply disable the password check for !v54! in the config. Post this to _conf.jsp:

<ajax-request action='setconf' updater='system.ts' comp='system'>
    <clipwd enabled='false' x-ruckus-vendor-code='' ruckus-vendor-code=''/>
</ajax-request>

 

[ms264556]

Depending on the firmware that you are running, you could also simply disable the password check for !v54! in the config. Post this to _conf.jsp:

<ajax-request action='setconf' updater='system.ts' comp='system'>
    <clipwd enabled='false' x-ruckus-vendor-code='' ruckus-vendor-code=''/>
</ajax-request>

Yes. Definitely.

The idea here was to retain the check but let you generate the passphrase yourself.

I personally prefer running a second ssh port with certificate auth only, which directly drops you to a root shell. I'll drop that here too, when I find it.

 

[dig]

Wireless mesh is not working with the virtual zd1200 and my R600 APs, ....

With much LLM help, it appears that the R600 AP firmware is mangling the packets as they cross the boundary between wired backhaul and the wireless mesh connections to mesh APs.

@ms264556 Would you have any suggestions for patching the code running on an AP running firmware provided by ZD version 10.5.1 ? I didn't see any root shell methods for this version in the page Obtaining a root shell on Standalone/Solo Ruckus APs | ms264556.net .

Update: With some more LLM help, the mesh is working now. The fix involves patching the AP firmware image to avoid inserting extra bogus characters into the packets crossing over from the wired backbone to the wireless mesh backbone. I will run it for a while and test it more before declaring victory. There was no need for root shell access, it was possible to manually install patched+unsigned AP firmware and then let them join the ZD network and get provisioned.

Otherwise I can try to submit a bug report to Ruckus to fix ZD, but probably should not expect much action to fix ZD at this late stage of its product lifecycle.

 

[ms264556]

With much LLM help, it appears that the R600 AP firmware is mangling the packets as they cross the boundary between wired backhaul and the wireless mesh connections to mesh APs.

@ms264556 Would you have any suggestions for patching the code running on an AP running firmware provided by ZD version 10.5.1 ? I didn't see any root shell methods for this version in the page Obtaining a root shell on Standalone/Solo Ruckus APs | ms264556.net .

Otherwise I can try to submit a bug report to Ruckus to fix ZD, but probably should not expect much action to fix ZD at this late stage of its product lifecycle.

If you ping me your address in a private message, I'll mail you a ZD1200 and R600s to use for testing. I was going to setup a ZD lab & give you the wireguard details, but I'm going to be busy at work for the next few weeks so won't have time.

Just as a datapoint though, I ran 10.5.1 with meshed R600s for a few years, and it worked great so long as I setup the AP over a wired connection first. So this is either broken by recent patch-releases, or works differently for ZD <=> AP vs ZD <=> L3 Firewall <=> AP.

Ruckus won't even release critical security fixes since 31.08.2025, so any AP bugfixing will have to be done by you.
I'm sorry, but I don't have an AP root shell exploit on newer ZD releases. If you're going to be doing heavy AP testing then it's probably easiest to revert to a 10.5.1 version supported by my solo instructions.
You can modify AP images using the tools I have in this repo.

For the R600, I think the ZD AP firmware is actually the latest released. But if you want to compare to the latest R600-compatible SZ firmware then you can decrypt the 5.2.2 AP patch release to extract the .bl7 AP images. I assume you're already comfortable using binwalk to pull the rootfs out of firmware images, but you can run a .bl7 through the decrypt tool to shred out the rootfs file otherwise.

 

[dig]

Just as a datapoint though, I ran 10.5.1 with meshed R600s for a few years, and it worked great so long as I setup the AP over a wired connection first. So this is either broken by recent patch-releases, or works differently for ZD <=> AP vs ZD <=> L3 Firewall <=> AP.

Ruckus won't even release critical security fixes since 31.08.2025, so any AP bugfixing will have to be done by you.

I think my edit of my last message happened after you read it.Good news is that there is a fix that is now being tested. The breaking change seems to have happened in the 10.5.1.276 release, and I expect all the earlier builds would properly support mesh backhaul for R600's. I don't know if any other APs would be affected, but probably R500 and T300 would have the same bad behavior starting with the .276 release that happened during 2024:

ZD1200 10.5.1 (GA Refresh 7) Software Release

10.5.1.0.276

IMG

2024-03-26

Thanks for your generous offer , @ms264556 , but I think I don't need any more equipment at this point. I will go ahead and post a bug report on Ruckus' support forum and they can ignore it if they want to. It might help some other people if they are having a similar problem with mesh.

 

[dig]

For the R600, I think the ZD AP firmware is actually the latest released. But if you want to compare to the latest R600-compatible SZ firmware then you can decrypt the 5.2.2 AP patch release to extract the .bl7 AP images. I assume you're already comfortable using binwalk to pull the rootfs out of firmware images, but you can run a .bl7 through the decrypt tool to shred out the rootfs file otherwise.

The firmware for the R600 in the SZ 5.2.2 AP patch release does not appear to have this bug. The release date for that was 2024-03-22 which is four days before the release date for ZD version 10.5.1.0.276 which introduced the bug. Here is an excerpt from the release notes for ZD which mentions something involving VLAN packet forwarding was changed, which might be related to this bug:
Resolved Issues in Build 10.5.1.0.276
• Resolved a VLAN packet forwarding issue. [ER-12565]

However I can't find any search results for "Ruckus ER-12565" in Ruckus' website or the Internet so it might be an internal reference.

 

[Bug91]

I can add a little information to the mesh issue in the latest release.
Afaik there are two public available ap firmware versions for SmartZone 5.2.2
the one with 2069 which is coming with the 5.2.2 release and an AP patch with 2122 as its version.

As we had some AP reboots and other stability issues with our SmartZone at that time (to be honest starting 2 years earlier and never fixed) I got access to some internal firmwares. There was an AP patch sent to me with firmware version 2132 for testing. There I observed the same mesh issue described in this chat. I then reported this issue to Ruckus just to be informed that 2132 would not be released and 2122 will be the last patch for 5.2.2.
I can confirm that for the affected SmartZone version all R500, T300 and R600 APs are affected by this issue when acting as a root mesh ap.

Maybe the implemented this issue as some dirty fix without proper testing the old hardware and then just stopped the development.
Another funny sidenote: other testing firmwares I recieved for 5.2.2 did not support the R500/R600 generation ap at all. It seemd to me that they just forgot that these APs should be supported according to their support matrix. After I noted this issue the support for the old APs came back in a later developed firmware.

Could you share the information how you fixed the firmeware with the mesh bug?

 

[dig]

Could you share the information how you fixed the firmeware with the mesh bug?

Thanks for sharing that experience!

Here is a python script that patches the firmware included with ZD version 10.5.1.0.282. After applying the patch, I needed to first install an ISI (eg R600_110.0.0.0.675.bl7 ) firmware to the R600 to permit installing this patched+unsigned firmware. Let me know if you want more detail about the behavior before/after this patch.

#!/usr/bin/env python3
"""Apply the experimental R600 ZD 10.5.1 mesh VLAN receive fix.

The patch changes one MIPS instruction in ieee80211_input.  It bypasses a
ZD-specific block which deletes the two-byte inner EtherType from a received
802.1Q Ethernet frame.  Input is accepted only when both the complete module
hash and the instruction bytes match the analyzed original.
"""

from __future__ import annotations

import argparse
import hashlib
from pathlib import Path


ORIGINAL_SHA256 = "93fdbc15992827f1e8d0f2ed954260f54ca923c3a7f04838ba4311a08d0faff7"

# .text has file offset 0x60.  The instruction is at .text+0x1e7e0.
PATCH_OFFSET = 0x1E840

# bnel v1,v0,+0xb -> b +0xb (big-endian MIPS32)
ORIGINAL_WORD = bytes.fromhex("54 62 00 0b")
PATCHED_WORD = bytes.fromhex("10 00 00 0b")


def sha256(data: bytes) -> str:
    return hashlib.sha256(data).hexdigest()


def main() -> int:
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument("input", type=Path, help="unmodified wlan.ko")
    parser.add_argument("output", type=Path, help="new patched wlan.ko")
    args = parser.parse_args()

    source = args.input.read_bytes()
    source_hash = sha256(source)
    if source_hash != ORIGINAL_SHA256:
        raise SystemExit(
            "refusing to patch an unknown module:\n"
            f"  expected {ORIGINAL_SHA256}\n"
            f"  actual   {source_hash}"
        )

    actual_word = source[PATCH_OFFSET : PATCH_OFFSET + 4]
    if actual_word != ORIGINAL_WORD:
        raise SystemExit(
            f"instruction mismatch at file offset 0x{PATCH_OFFSET:x}: "
            f"expected {ORIGINAL_WORD.hex(' ')}, got {actual_word.hex(' ')}"
        )

    patched = bytearray(source)
    patched[PATCH_OFFSET : PATCH_OFFSET + 4] = PATCHED_WORD
    args.output.write_bytes(patched)

    print(f"input:  {args.input}")
    print(f"sha256: {source_hash}")
    print(
        f"patch:  0x{PATCH_OFFSET:x}: "
        f"{ORIGINAL_WORD.hex(' ')} -> {PATCHED_WORD.hex(' ')}"
    )
    print(f"output: {args.output}")
    print(f"sha256: {sha256(patched)}")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

 

[Bug91]

Hm, thank you for sharing. However I assume this patch is not applicable as it is to the SmartZone image directly. Would you share some more information? I'd like to test...

 

[dig]

Hm, thank you for sharing. However I assume this patch is not applicable as it is to the SmartZone image directly. Would you share some more information? I'd like to test...

This patch script can be used to fix the behavior in the R600 firmware that is bundled with ZoneDirector 1200 software version 10.5.1.0.282.

To test it today, you would downloaded that ZD software from Ruckus, then decrypt it, then extract the AP firmware for R600, then apply this patch, and then install an ISI firmware on the AP (such as R600_110.0.0.0.675.bl7), then you can install the patched AP firmware over that. It's a long process that can be automated, and I am working on making it easier but that improved version is not yet ready for testing. I hope to have something in the next days.

 

[Bug91]

That's what I assumed. I wanted to test your fix with the SmartZone controller. However I assume that the ZoneDirector Firmware will not work with SmartZone.

 

[dig]

That's what I assumed. I wanted to test your fix with the SmartZone controller. However I assume that the ZoneDirector Firmware will not work with SmartZone.

I think that is correct, you would need to apply the same method to the smartzone software download: decrypt, extract r600 firmware, apply patch, install ISI firmware on r600, install patched sz firmware on r600. If you give an LLM the python script it might be able to do it for you.

 

[dig]

Announcing the first release candidate for the Virtual Zone Director 1200 experimental project!

Notable features:
* runs as a docker container on linux, instead of a dedicated hardware box
* supports a wider range of Ruckus AP models than any single version of Unleashed. Especially useful for older AP models such as Rx00 and Rx10, and systems that involve both newer and older models of Ruckus APs.
* includes patches to enable root shell and ssh access with ECDSA encryption (as well as the older RSA standard)
* includes a new menu item and reporting tool: Ping Monitor for detecting and investigating network performance issues. Stores 30 days of ping data and network configuration snapshots for each connected client and AP.
* includes patch to fix bug in the AP firmware included in ZD 10.5.1.0.276+ that broke mesh operation for R600 (and probably R500 and R310 and other AP models), note that some extra effort is required to install this unsigned firmware on affected APs

Reasons why this might not be preferable to Unleashed:
* introduces a new single point of failure, vs Unleashed's master-failover behavior
* untested software from some random person on the internet

Beware! This ZD software is new and largely untested and not yet as easy to install as it could be. You should expect bugs! It is suitable for non-production testing by people who are familiar with docker and git. For those reasons, it is currently in a separate branch of the github repo to discourage casual use. For the brave:
GitHub - dbro/zd1200 at public-release-candidate

The README file in the repo has instructions and technical explanations. Recommended setup is to use a dedicated USB ethernet dongle to connect this docker container to your management VLAN.

In general, it should behave the same as a hardware based ZD1200. After it first starts you visit the wizard at 192.168.0.2 to set up the initial settings.

Added to the ZD management interface is a new Ping Monitor in the "Troubleshooting" menu. This is meant to provide information to answer the questions "which devices have poor connections? when is that happening? what is the state of the APs and mesh when it happens?" It acts like a cron job that pings all the connected devices and stores the results for 30 days. It also snapshots the configurations of the APs, clients, and mesh. Then you can see trends and look at diffs of the network configuration snapshots. I was using HomeAssistant to measure ping response times, but having it in ZD adds more information about the network configuration.

In case it helps to see an example of how to configure the virtual ZD in docker, these are the docker-compose environment variables I use to run the virtual ZD for my home network which has 5 R600 APs connected by wired and wireless mesh backhaul. I use Portainer to manage it along with about 20 other docker containers running other services (eg ntp).

ZD_VENDOR_DIR=/opt/docker/zd1200/vendor
ZD_VENDOR_ARCHIVE=zd1200_10.5.1.0.282.ap_10.5.1.0.282.img.tgz
ZD_VIRTUAL_BUILD_ID=dd933e1
ZD_TAP_IF=tap-zd
ZD_CONTAINER_NAME=zd1200
ZD_RUNTIME_VOLUME=zd1200-runtime
ZD_STATE_VOLUME=zd1200-state
ZD_SERIAL=120012001200
ZD_MAC1=02:52:54:12:00:01
ZD_ENABLE_ECDSA_SSH=1
ZD_ENABLE_ROOT_CLI=1
ZD_SUPPORT_ENTITLEMENT_END=2099-12-31

Feedback is welcome, either here or on github.

 

[TonyArrr]

Reasons why this might not be preferable to Unleashed:
...
* untested software from some random person on the internet

Whaaaat? That is always the best software!!!

Seriously though, good work on this, very impressive. If I had more than 1 AP I'd be jumping right on in