802.11g issues after 9.8.2

Question

We have a wlan on a zd1100 with three TrendNet 802.11g print servers. Replacing these devices is not an option at this time (long story, I know g sucks, but I'm stuck with these for now.) The wlan is using WPA-mixed encryption because these print servers can only do WPA2-TKIP and there are also iPads on the same wlan doing WPA-AES.

Everything has been working perfectly fine for several years, until I recently upgraded the ZD from 9.4.something to 9.8.2 (doing all of the necessary in-between upgrades as well.) Now these 802.11g pservers are having problems connecting to the same wlan they always have. The symptom is that they will immediately connect, but the ZD shows the clients with NO IP address, thus they cannot be communicated with. I thought this might be DHCP related so I set a static IP on one of the pservers with no effect... it still shows up with no IP address in the ZD. HOWEVER, after a LONG time (like 6-8 hours) the pservers WILL magically start talking over IP again and everything is normal, until they are power cycled and the whole scenario repeats.

All that is to ask if there are any "levers" in the ZD I can adjust to make these pservers operate as they used to? Clearly something changed along the way from 9.4 that these units don't like, but nothing I've fiddled with in the web UI has made a difference. I was wondering if there might be some CLI settings I could adjust that affect how g devices work?

If there's nothing I can do on the current firmware, is it possible to go BACK to 9.4? If so, how?

unknown · Answer

Thanks for the detailed info! I will try this when I get a chance, but I don't think it's my issue (unless I'm misunderstanding what those commands do.) While the problem print servers ARE using TKIP, the iPads on the same wlan are not... which is why I have "WPA-Mixed" as the encryption mode.

Troubleshooting further, I realized yesterday there was a fimrware upgrade for these print servers that enabled AES, so I upgraded one with high hopes... with the same result. Said another way, even when using AES, these problem devices still do not work, so I don't think TKIP is the culprit at all, now.

It seems to be something more fundamental that changed between 9.4 and 9.8 (and since I upgraded through the necessary in-between versions rapidly, I have no idea if, say, 9.6 was when they would have stopped working, or if it really is 9.8 that's the culprit.).

The craziest part of all of this is that the devices DO magically start working (after 12am... no idea if that's significant) and work fine until they are rebooted via a power interruption. I suspect these are just terrible wifi devices, yet I cannot escape the fact that they worked perfectly against this ZD at 9.4 and now do not a 9.8, with absolutely zero changes to the clients. We have a mystery, for sure.

michael_brado · Answer

And Jim, we hope you'll always save a ZD backup before you upgrade, even add the version digits to the filename to remind you what version its from, so you could revert back after a downgrade if needed.
Our current firmware may incorporate the backup, but having a soft copy is good archival material.

sid_sok · Answer

This is from our KB:

Starting from 9.8 firmware version, the exclusive option for choosing the TKIP algorithm has been removed across the webUI interface.

However, we can still configure this option from the Zone-director's Command line interface.

SSH login to the Zonedirector using a tool such as "Putty" and execute the following set of commands across the Zonedirector to configure the TKIP based algorithm for the wlan.

ruckus>enable
ruckus#config
ruckus(config)#wlan

Eg:- ruckus(config)#wlan "Verifone"

ruckus(config-wlan)#open wpa passphrase  algorithm TKIP

Eg:- ruckus(config-wlan)#open wpa passphrase test1234 algorithm TKIP

ruckus(config-wlan)# exit
ruckus(config)#exit

Once after executing the above command, the WebUI interface will prevent configuring the wlan encryption options. However, still further changes can be made from the command line interface.