MX68W - WPA2 SSID Broadcasting As Open Network

[dan_c]

We're running into an issue with an MX68W at one location, and possibly a second location, where one of two WPA2 encrypted SSIDs will be found to be broadcasting as an open network. When this occurs, client devices attempt to join the network but they are unable to authenticate or get on the network. This is affecting iOS and Android devices thus far. There are no other identical SSIDs being broadcasted that would conflict or cause this. This is a unique SSID. This occurs to the same SSID every time the issue occurs, in that the issue doesn't alternate across both SSIDs. 

We have switched positions of the SSIDs in the dashboard but the issue persisted to the same SSID after the switch thus ruling out fault in the position. 

Disabling/enabling the SSID does not resolve the issue. The only fix is rebooting the MX, but the issue persists sporadically occurring several times throughout a weeks time. 

For what it's worth, we encountered a very similar if not identical issue with a Z3 unit for a different deployment, and that was never resolved. 

Has anyone run into this before, or have suggestions?

[dan_c]

To add, we are on firmware version 14.39, and have not yet switched codes. We have multiple units running the same 14.39 version and they have not performed this way. 

[PhilipDAth]

Does the SSID contain any special characters such as spaces, percent symbols, etc?

Some dumb clients don't have SSIDs with more than about 15 characters very well.

[Uberseehandel]

---

@PhilipDAth wrote:

Does the SSID contain any special characters such as spaces, percent symbols, etc?

Some dumb clients don't have SSIDs with more than about 15 characters very well.

---

Emojis, diacriticals, non-roman lettering, all cause problems. When naming SSIDs, avoid the urge to make them cute.

[dan_c]

Thanks for the reply! It's the company name totaling 11 alpha-characters including a single space. 

[Uberseehandel]

Try turning the space into an under score _ 

[dan_c]

Thanks for the suggestion, and we will likely do this in our lab environment as we are receiving the unit back and deploying a replacement to isolate hardware vs configuration. We do have 12 of these units currently deployed, and only 1 (possibly 2) locations have reported this issue.