Hi has anyone seen an issue where a client is unstable when it tries to connect to a hidden SSID but is OK when it connects to a visible SSID?
That could be a bug in the client firmware or driver! Hidden SSID’s are generally discouraged these days, so it’s possible that the client vendor didn’t thoroughly test their gear on hidden SSID’s.
Is there a specific reason why you need to connect the client to a hidden SSID? If not, it sounds like the workaround might just be “unhide the SSID”. I’m interested to hear more background about the issue!
Hi Joel thanks for the reply, I can’t go into too much detail in a public forum but basically we were told that we should hide SSID’s (but this was a long time ago and we all know it’s easy to find out a hidden SSID’s name). We had a particular device that refused to connect to a hidden SSID using the UNII-2 channel bands 52/56/60/64 but ok like I say when visible. Is there anyway I could use my Eye P.A to analyse this problem?
Some of my IoT devices for home automation (specifically, Leviton Decora light switches) had issues with connecting to hidden SSIDs. In fact, they even had trouble connecting to encrypted SSIDs. But after a recent firmware update, they are now able to use encrypted SSIDs. I decided to keep the home SSID visible, and just enabled WPA2.
The only other devices that seemed to have issues with hidden SSIDs are older computers that I try to keep alive.
This is a good article that addresses the issue:
Thanks for the reply, it does seem to be a certain device that is unable to connect to 5GHZ on frequency channels 52/56/60/64