topic Re: Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152 in Unleashed

Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152

louis — Fri, 28 Mar 2025 13:58:57 GMT

I have 7 Leviton smart switches connected to Ruckus Unleashed, 3x DW1KD, 1x D26HD, 2x DW6HD, and 1x D215P. All of these devices have exactly the same connectivity issues with Unleashed 200.16 and later. All of these devices work perfectly with Unleashed 200.15 and earlier. The connectivity problems are worse with Unleashed 200.16.0.402 and 200.17.7.0.139 than with Unleashed 200.17.7.0.152, but the issue is still present in all Unleashed versions 200.16 and later. I'm testing with access point models R850 and R750, the behavior is the same.

Leviton Firmware

Current firmware versions of the Leviton devices (model number - firmware version):

DW1KD - 1.7.1;CP 1.13
DW6HD - 1.7.1;CP 1.13
D26HD - 1.6.6
D215P - 1.6.6

Unleashed 200.15 and earlier

Leviton switches have no connectivity issues.

Unleashed 200.16.0.402 and 200.17.7.0.139

Leviton switches will initially connect after rebooting the Unleashed system, but will only stay connected for a few minutes to a few hours before disconnecting. Once the Leviton switches have disconnected, they will not reconnect. I've waited days to see if they could eventually recover on their own, but they could not. Rolling back to Unleashed 200.15 permanently fixes the connectivity issues for all of the switches.

Unleashed 200.17.7.0.152

Leviton switches have connectivity issues similar to what I've described for earlier Unleashed releases, but the issues are not as severe. There are two improvements with Unleashed 200.17.7.0.152. First, the switches stay connected much longer, typically hours to days before they lose connection. Second, the switches eventually reconnect on their own after a few hours to a few days. Rolling back to Unleashed 200.15 permanently fixes the connectivity issues for all of the switches.

Client Troubleshooting

I've tried a few things to get these clients to reconnect once they've lost connection with the problematic Unleashed versions:

Power cycle the Leviton switches. No effect. I cut power to the Leviton switches for 5+ minutes before powering them back on, but they will not reconnect.
Delete client while client is trying to connect and while client is powered off. No effect.
Block and unblock client while client is trying to connect and while client is powered off. No effect.
Power cycle the access point the client is trying to connect to. This allows the client to immediately reconnect, but only temporarily. Eventually the client loses connection again, the problems continue as before.
Roll back to latest Unleashed 200.15. All issues are resolved, clients have no problems connecting or staying connected.

Following is a screen cap from Unleashed client troubleshooting. It shows one of the Leviton switches after it has lost connection and is trying to reconnect, but cannot. This pattern continues forever and is exactly the same for Unleashed 200.16.0.402, 200.17.7.0.139, 200.17.7.0.152.

Following is a screen cap from Unleashed show details for the same device in the Unleashed client troubleshooting screen cap above. This shows the device during the DHCP negotiation period seen above. The device appears to be unable to acquire an IP address and eventually disassociates itself. I've made no changes to the clients, network, or Unleashed configuration while testing. The only variable has been the Unleashed firmware version that is deployed.

Re: Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152

BobaEnjoyer — Thu, 27 Mar 2025 22:53:54 GMT

Anecdotally, I currently have 2 of the Decora Smart Mini plug-in switch, 2nd gen (D215P) running the Early Access Matter firmware 2.1.25. Been running about a month or so, starting with Unleashed 200.15 on a R710 then currently Unleashed 200.17 on a R650. I'm using Home Assistant OS baremetal with the Matter (Beta) add-on and integration. (Matter uses a ton of IPv6.)

Several weeks ago both smart plugs completely disconnected from Home Assistant and refused to advertise their IPv6 addresses and were unavailable. They were still completely connected to the WLAN and still had IPv4 addresses assigned from my router's DHCP service. They were effectively just invisible to Matter and Home Assistant. I had to remove them and go through the pairing process from scratch.

So far so good, but I still want to find out why they dropped off so I can prevent it happening again. I think it happened when I rebooted the Home Assistant PC.

Of course, our issues are very different. I'm only posting this because I do have a couple Leviton D215P connected to a Ruckus AP running Unleashed 200.17 and the Wi-Fi aspect of it has been solid for me. Same with their ability to obtain an IPv4 address with DHCP.

What firmware are you running? I had to join Leviton's Matter Early Access program to get Matter firmware 2.1.25, so we're probably on different development branches if you're using the traditional firmware it comes with out of the box.

Re: Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152

louis — Fri, 28 Mar 2025 14:16:06 GMT

Thanks for the reply, interesting that you've not experienced similar connectivity issues with your D215P. I've been suspicious that there may be something specific about my Unleashed configuration that is causing the problem, but I'm not sure what it could be. The fact that rolling back to 200.15 fixes everything for me each time is a strong indication the problem is in the newer Unleashed firmwares, but it's possible the issue arises in the newer firmwares only with some specific Unleashed configuration.

I wasn't aware that Leviton was beta testing a Matter compatible firmware. Perhaps that would fix this issue, at least for my 2nd gen Leviton devices (D26HD, D215P). It doesn't look like my 1st gen devices (DW1KD, DW6HD) are eligible.

I've edited my original post adding the firmware version of each Leviton device and a screen cap showing the client's details when it is connected, but unable to acquire any IP address.

Re: Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152

BobaEnjoyer — Fri, 28 Mar 2025 20:31:03 GMT

Wonder if this is somehow related to using DPSK. Maybe test with creating a temporary new 2.4GHz WLAN that uses a traditional single password?

Re: Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152

louis — Mon, 31 Mar 2025 14:59:39 GMT

That's worth a test. I set up a second wireless network yesterday and moved only my Leviton devices to it. The new wireless network is using exactly the same settings as the original network, but no DPSK, only a traditional WPA2 single passphrase. If there are no connectivity issues for a week, I'd say DPSK is most likely the problem with the newer firmwares. I'll report back if something loses connection or if everything remains stable for a week.

Re: Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152

louis — Wed, 09 Apr 2025 22:02:53 GMT

10 days and no disconnects. It certainly seems like DPSK is the problem with the newer firmwares. It's interesting that only Leviton devices seem to have an issue with DPSK on the newer firmware. I have several other kinds of devices connected to the wireless network, but I've yet to notice any issues with them connecting using DPSK.

Re: Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152

BobaEnjoyer — Wed, 16 Apr 2025 07:54:44 GMT

That's very interesting, honestly. I've sent some feedback to Leviton Support (via their website), and they replied fast and said they would forward to their engineering team, but I haven't heard back yet. (I wanted their Matter-over-WiFi beta firmware to 100% be local and stop phoning home to Leviton servers on AWS every minute or so.)

DPSK and other vendors' implementations seem really interesting, but I believe they only work with WPA2-Personal, so their days are numbered. I think WPA3-Personal (SAE) doesn't allow for dynamic pre-shared passwords. [Edit: I realize many IoT companies use ancient 802.11n 2.4 GHz radios even in 2025, so we're stuck with WPA2-Personal, hence why it'd be nice for them to work with DPSK. I get that as well.]

I dunno whether the bug is Ruckus Unleashed changing stuff in 200.16 and 200.17 or if Leviton magically doesn't work with the newer Unleashed firmwares. We'd have to almost do a packet capture (for days at a time) and drill down. Sounds tedious haha.

Re: Connectivity issues with Leviton devices Ruckus Unleashed 200.17.7.0.152

louis — Tue, 20 May 2025 21:24:10 GMT

Unleashed 200.18.7.1.302 is still just as broken with 1st generation Leviton devices. However, 2nd gen devices seem to be working better on 200.18.7.1.302. Still some flakiness, but they lose connectivity less often, and reconnect faster, it's good enough for me. I swapped out my 1st gen devices for 2nd gen equivalents. I also switched to R770s, but they have the same issues with Leviton devices as the R850s did.

For me, DPSK is the most important feature offered by Ruckus wireless, I switched to Ruckus for DPSK. At the time, Ruckus had the only dynamic VLAN assignment by pre-shared key solution that worked well enough and didn't require licensing fees in perpetuity. There's a lot of confusion going around about DPSK and WPA3, Ruckus' current solution "DPSK3" actually requires a mixed mode WPA2/WPA3 network configuration. Auth happens on WPA2, and the client is allowed to transition to WPA3 while staying on the same VLAN they were assigned by their WPA2 PSK. Sadly, it is only available for Ruckus One and SmartZone. There was a rumor this would come to Unleashed in 200.18, but it did not. It's sad Ruckus has been dodgy about explaining exactly how they're doing DPSK3 leveraging mixed mode. And if you have WiFi 7 enabled APs like the R770s, you can't leverage all performance features of WiFi 7 in mixed mode. So although Ruckus advertises "DPSK3" as enabling DPSK for WPA3, it kind of doesn't, there are too many caveats. It doesn't sound like DPSK will be impossible to implement on WPA3, but it certainly will require a different implementation than what was done for WPA2. Hopefully a solution becomes available from someone, and if not Ruckus, I will be moving on.