I haven't actually got one running yet, some of my long term decisions will be based on what exactly those unspecified issues are. I was hoping anyone here could enumerate their own experiences and name specific issues and problems so I know what to expect.
Ruckus Wireless as an Unifi alternative?
- Thread starter pcmoore
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
It worked fine. But throughput on my other APs dropped to zero, then recovered when I switched back to 80MHz. Maybe it was a fluke but there are notes elsewhere that 160MHz doesn't work on this chipset.
I'd rather say "don't use 160MHz" than be responsible for killing your neighbours' internet.
Something I've noticed (but not confirmed yet), I am able to trigger the panic if I set the System Time (Admin & Services -> System).
Even if I don't change the system time, but simply press APPLY (to reapply the already set time), a panic occurs within 0-5 mins from hitting the button.
Based on the previous days' behaviour, I believe the next panic will happen every 24 hours (+/- a few mins) from that time.
I've been running .203 for two weeks without any issues on an r730.
Sorry, I've been running .203 for over 48 hours now, no panics.
I applied the system time settings & waited 15 minutes - nothing bad happened.
I changed the timezone to eastern australia, applied the system time settings & waited 15 minutes - nothing bad happened.
There are probably enough data points for you at this point, but here's another one: I've been running my r730 on .203 for 16 days with no panics.
Thanks for the reports @adman_c @vulture @ms264556 @Sealside.
Mine seemed to be ok after a reflash, as I couldn't trigger a panic simply by APPLYING the System Time, however it panicked again at ~802am today.
I've flashed it to R730 Solo v114.0.0.0.6565 and am leaving it running as suggested earlier.
I assume the best way to detect a kernel panic is if the Uptime appears less than the actual uptime? (The logs looked much less useful in SOLO.)
I booted it up at 1905hrs (uptime currently 40mins), so I'll check if it says '24hr uptime' at this time tomorrow.
Mine seemed to be ok after a reflash, as I couldn't trigger a panic simply by APPLYING the System Time, however it panicked again at ~802am today.
I've flashed it to R730 Solo v114.0.0.0.6565 and am leaving it running as suggested earlier.
I assume the best way to detect a kernel panic is if the Uptime appears less than the actual uptime? (The logs looked much less useful in SOLO.)
I booted it up at 1905hrs (uptime currently 40mins), so I'll check if it says '24hr uptime' at this time tomorrow.
Out of 8 730s I bought on ebay, two had hardware issues. One had a burnt out serial port and would panic early in the boot. Another had a burn out 5GBe port even though it would power the AP over POE but there was not connection to the switch. On that one I had to force bt power mode in order to enable the second port (done over serial via CLI) and then use that to update it to unleashed over the web UI. So, there are problematic APs being sold out there and based on your observations you may have a hardware issue somewhere causing this.
How did you confirm your R730 was faulty when you had SOLO installed?
Was there something shown in the logs or did you find your uptime was less than it should be (and deduced that it was resetting due to kernel panics)?
Ruckus Primer: Ultimate AP Reset Technique without WebUI
Saw this on reddit, could be useful for someone here. The setup tftp server section is sparse, but Fohdeesha has us covered here.
Setting up tftp: Windows, Linux, macOS Fohdeesha
Saw this on reddit, could be useful for someone here. The setup tftp server section is sparse, but Fohdeesha has us covered here.
Setting up tftp: Windows, Linux, macOS Fohdeesha
Using crossbreeder was a funny choice - this tool just runs the SSH
fw commands. For 1 AP, it's more effort to download and configure the tool than just running the necessary commands, and useful output from the commands is hidden by the crossbreeder GUI.Also, an "ultimate" guide would ideally mention the last-chance option of using a serial connection.
So, I've gotten an R730 but I'm having trouble with the 5ghz radio dropping clients. I haven't crossflashed; I'm just running the latest available Solo firmware. Any suggestions on what to look for in the support info text? Both clients get disassociated at the same time but the log tab in the interface doesn't show anything suspicious.
Edit: Running the Solo version from: Ruckus Solo Access Point 114.0.0.0.6565 (GA) Software Release (R730) | Software Downloads | Ruckus Wireless Support
Edit: Running the Solo version from: Ruckus Solo Access Point 114.0.0.0.6565 (GA) Software Release (R730) | Software Downloads | Ruckus Wireless Support
Last edited:
Did you maybe choose Smartselect for the channel (in Radio 5 > Common)? I haven't run Solo long-term in ages, but I'm pretty sure the Smartselect default behaviour used to be channelfly. If I had clients which couldn't handle the AP jumping around the channels after a reboot then I'd just pick a channel manually.
I did; I'll try turning off smart select / ChannelFly.
Somewhat related: I did note that while running a speed test on a client while it was still connected to the R730 that the Ubiquiti SSID throughput collapsed. This was with 80mhz channels and the Solo firmware. I suspect that the issue here was actually that the two APs are about a foot apart and the RF frontend on the UAP-AC-HD was just overloaded.
I'm not sure what this tells me about my r730...
but it's been running on Solo v114 for 4 days 5hrs without any problems/crash.
For those who used solo to confirm they didn't have a faulty/dodgy r730, what test/metric did you use?
I've got a copy of openspeedtest running internally; I pushed a long running test and have kept an eye on association time.