We have a ZD1200 with 22 AP ́s and 20 wlans, they are different venues (shops) in a few ones we have 2 SSID and we can connect to the guest SSID but no to the private one, the configuration has been checked with Ruckus support and tried many cloning and new SSID with no luck with the connection.
Thank you in advance.
to get real help you must be much more detailed about your problem.
What authentication you use, what are the clients, what messages are in the ZD event log (enable debug to see more), also if problem really exists with many different clients or it was tested with your laptop only?
Some ideas to check anyway:
If you use Radius authentication for example, issue probably is Radius communication related. Check if requests reach Radius server at all for starters.
If you use WPA2-PSK, and have problem with 802.11a/b/g devices -- check that you don't have option checked (advanced options): Enable 802.11r FT Roaming.
When checked, only 802.11n/ac devices can connect to the network, b/g try to connect and fail.
Also sometimes improper WPA2 passwords doesn't work with some clients (try to set password with just letters and numbers, no special symbols).
Some client devices (especially some phones) can't connect, if AP work on channel other than 1-6-11. Try to set AP to use only this channels.
Hope it helps...
you need to look at the AP support file for REAL reasons of failure to connect.
I would suggest that try WPA/TKIP as i have seen devices trouble connecting on AES...
similarly disable mixed mode too..while testing..
do test with multiple type of devices like smartphone, tablet and laptop just to make sure you are not seeing issue with specific brnad/type of device
you should never use TKIP or mixed mode, except very special situation forces you.
There are very few devices still around, which really need TKIP. Devices not supporting WPA2 must be 10 years old, as for that time this is a mandatory requirement for any Wi-Fi certified device. TKIP ruins performance of AP, making it just 802.11g AP, and is insecure, so it may be used just in some very specific cases, for example - to serve old industrial equipment, which is costly or impossible to replace.
It is not a good idea to allow TKIP for any public environment, as new devices don't need it at all.
Hope it helps...
I want to give you the maximum of information about this costumer to resolve it ASAP. The deployment of this system is the following:
§ Our costumer has a Zone Director 1200 (firmware version 188.8.131.52 build 59) in their central office, which is behind a firewall. The public IP is x.x.x.x and its LAN IP is x.x.x.x.
§ Ruckus APs (R300) are distributed in different Restaurants, and each one has two SSID: “xxx” which is the private WLAN just for internal use with a WPA2 password, and a Guest Access (“xxx” in this case) WLAN which redirect to the “Terms and conditions” page and without password.
§ Each restaurant has a router provided by the ISP which control the DHCP. The IP of the router of this restaurant is 192.168.1.1 and its MAC address is already Whitelisted.
We are facing different problems, sometimes the internal WLAN works and other times it doesn ́t and the same happens with the guest access WLAN in a random way. IOS, Android and Windows devices have been tried with the same result.
What I mentioned about channels still may apply - check it practically. But if problems comes and go, check connection latency of your connections, If it is in the area >50msec normally, when it comes to 150 msec you'll get timeouts from clients just because too slow communication between ZD and APs. It is usually the reason if links are slow and use old technology (DSL), and almost never on fiber networks. It may be also case if you use provider, which actually outsource last mile and runs some overlay (PPOE or PPTP) over other provider networks and having router somewhere far from the end-user network. If this is a case, you may have problem which can't be resolved without changing ISP or using different solution.
Anyway, the best way is to enable debug on ZD, than, after having this problem, find affected APs IPs and client MACs, download debug file and look for messages related to this APs and clients. This will say what is reason of disconnect (timeouts will be obvious as well as any other specific reasons).
To analyze debug file you need analyzer tool (available for Ruckus partners on support site), or you can open case and ask Ruckus support to look on the file.
Another thing I often have seen -- empty DHCP pool. It happens, when a lot of clients are moving around, but DHCP server has long hold time (7 days, for example). In public places almost any size of DHCP pool can be completely used in just hours. In places with big client number and a lot of moving you want to use 1-2 hours or even less hold time.
In a big shop you can get 256 address pool full in 5 minutes, so you want to use really short hold time and bigger pool...