Couldn’t find anything in the support FAQ on that.

Have you tried un-hiding it, connecting the Sonos then hiding it again?

Why is your SSID hidden? It provides no additional security and can make you more of a target.

https://www.acrylicwifi.com/en/blog/hidden-ssid-wifi-how-to-know-name-of-network-without-ssid/

When my SSID is visible, One SL connects without any issue. But once i set my SSID as invisible, the already connected One SL loses connection.

The SSID is also password protected, invisibility is just to add an extra layer of protection.

Security benefits are very minimal. A determined hacker has tools, may not notice that you've hidden the SSID, and certainly won't care.

A hidden SSID can be determined by a local wireless sniffer as clients broadcast the SSID in plain text. It’s the only way they can connect.

More ominously perhaps, a mobile which connects to a hidden SSID at home will remorselessly broadcast that SSID when out and about. If there’s any way of associating that SSID with the home address this could be significant. 

Hi @michaelweku 

Welcome to the Sonos Community!

Connecting to hidden SSIDs is definitely supported, so I’m not sure what’s going wrong for you. I recommend you get in touch with our technical support team who have tools at their disposal that will allow them to give you advice specific to your Sonos system and what it reports.

I’m with the others though - there’s not a lot of point in doing so as it is easy enough to circumvent the hiding; anyone who knows enough to hack their way onto your network will not be stopped by hiding the SSID.

I hope this helps.

This is one good reason to hide an SSID: it totally blocks WPS. Some WiFi kit, despite being instructed to disable WPS, insists on leaving it available in some form or other. Hiding the SSID fixes this.

I have the same issue.

I’ve got a fully working Sonos setup on a dedicated hidden SSID consisting of Play:1, Arc and Era 100. They all work flawlessly and connects straight away if rebooted etc. When I added a pair of One SL’s to the mix however, they never attempted to connect to the SSID according to my WLAN controller’s log, but once I made it visible they connected straight away. Hiding SSID again while the One SL’s are connected keeps them online until they get rebooted or lose connection any other way.

Yes, I’m aware a hidden SSID is not a security layer and I don’t treat it as such. The speakers are the only devices to connect to this SSID and gets assigned a dedicated VLAN. I restrict multicast traffic on my main SSID.

If the devices think the stored SSID is unhidden they possibly don’t poll for it when it is hidden.

You ought to be able to add a hidden SSID/password using the appropriate option in the app. However it may help if you temporarily connect your mobile to that SSID first and configure the SSID to be the only one that the mobile will auto-join/auto-connect to.

Thanks for the input.

Usually it’s the client sending out a beacon for SSID’s, but yeah, there is a slight possibility that they could refuse connecting to a hidden network, but that would be deliberately and it’s weird that it only pertains to one specific model out of those tested. 

When I onboard new devices I do it on the same L2 network from a device connected to the same SSID just for simplicity, but it never gets past connecting to the SSID when it’s hidden, so for the purpose of completing the setup I tested by unhiding it. As mentioned, for all other devices this step went just fine.

I’ve also moved back and forth from different networks within the app, so I don’t think that’s the issue.

Diagnostic ID 1754776466 for any Sonos employees lurking around. :-)

After the mobile informs the new Sonos device of the SSID/password during setup usually the next step is for both the mobile and the Sonos unit to disconnect, then each separately reconnects at L2 (followed by L3 obviously). The controller app then needs to re-establish a connection with the unit in question.

I’ve sometimes seen this fail, often simply because the mobile’s gone to the wrong subnet. It might be worth double-checking that the rediscovery isn’t being blocked somehow. 

I’ve seen that too, especially if you have multiple stored networks it can connect to (and defaults back to a separate SSID). I made sure to delete all other eligble networks and verified the mobile controller is in the correct subnet after reconnecting. 

There’s no assoc or auth logs that the speaker attempts to connect so I’m pretty certain this is a model specific behavior.

Within seconds of unhiding SSID:

<NOTI> |stm|  Assoc success @ 20:12:52.410340: c4:38:75:77:xx:xx (Speaker): AP 10.xx.xx.xx-9c:1c:12:82:xx:xx-SR18-AP225

I’m assuming these speakers utilize the wpa_supplicant component and my guess is that the wpa_supplicant.conf is configured with ‘scan_ssid=0’ which scans for the SSID using a broadcast Probe Request frame for visible networks. ‘scan_ssid=1’ on the other hand uses directed Probe Requests and will allow the speakers to connect to hidden networks.

If the above is true I’m clueless as to why that only applies to the One SL speakers (and possibly others except the ones I have tested).