Skip to main content

Hi,

I have issues with my Sonos products getting disconnected - they show up as disconnected in the app. Sometimes the app fails to detect the Sonos system at all. After rebooting the speakers it runs fine for a day or so until the problems start again. I always thought this might be due to bad wifi because I was living in a small apartment in a big city and there wasn’t much I could do about wireless interference. However, I recently moved into my own house, updated all ethernet and wifi infrastructure - yet I still have these issues. The weird thing is that other devices on the same network run totally fine (streaming Netflix, etc.) and I do get a ping reply from all Sonos speakers all the time - so there are no “real” network disconnects/STP problems, etc. I used to have the same SSID for 2,4Ghz and 5Ghz Wifi, but recently splitted it, giving the 5Ghz a new name. I moved all my speakers into the new Wifi - I can tell from the router that they are connected to the correct SSID and the Sonos app also shows this in the rare cases when all speakers are connected. I also did a factory reset on one of my Play:5 speakers, but that device is also having this issues again just a day after the reset. Oh - I also did try to connect the Play:5 by ethernet, but even then the app complains about not finding it. I see all Sonos speakers moving from the Wifi to the new Sonosnet and it works for a couple of hours, until the problems start again…

I finally want to get this sorted, but I am a bit unsure how to proceed...

First off, I suggest you run with fixed ip addresses for your devices. A frequent problem on these forums boils down to duplicate ip addresses causing issues. 
Second, it’s worth setting your wifi to a fixed channel - use channel 1, 6 or 11. If you keep with Sonosnet put that on one of the other two channels. 
Third, tell use more about your network kit to see if there’s any specific advice on offer. 


Thanks for getting back to me! As far as I know there is no way to assign a Sonos device a fixed IP address - so you are probably talking about DHCP reservations. This is the way I have the system set up currently (although only since yesterday, when I started monitoring their connections through ping).

Since Sonos devices announce their hostnames with something that contains “Sonos” in the name, I am pretty confident I got them all!

As for the Wifi Channel: Unfortunately my Accesspoints (TP Link Deco (BE85)) do not allow me to set a channel manually. However, they also don't switch them around randomly - the channel stays the same unless you run a “network optimization”. My 2,4Ghz channel is currently set to channel 4 - with 40 Mhz width). My wife upstairs runs her 2,4Ghz wifi on channel 11 with 20 Mhz width.
HOWEVER: This is not the SSID the Sonos devices should connect to! The 2,4Ghz is reserved for IoT devices.
All Sonos devices should connect to my 5Ghz Wifi instead - which is running on channel 42 (with 240Mhz width). As far as I can tell through the app this is the case - it shows all Sonos devices on 5Ghz and none on 2,4.
As for a general overview of my network:
Like mentioned I am using TP-Link Deco Mesh devices in a pure Accesspoint configuration. I have one BE85 on the second floor, where also all Sonos speakers are located. This BE85 is connected to a XikeStor switch on floor one. This switch also connects to:

  • A second BE85 in a dedicated VR room
  • A XE75 which is mainly handling the cameras

All uplinks are 2,5Gbit. The router, which is assigning the IP addresses, is connected to the XikeStor - but only with a Gigabit uplink. That shouldn’t matter, however, because the packets from the Sonos decides don’t pass the router at all in this configuration - I am only playing local stuff here (or not playing anything at all - as they tend to disconnect even without playback).

During my tests with Sonosnet I connected the Play 5 to the BE85 on the second floor via cable - the one device every other Sonos speaker _and_ my smartphone are connected to. But even then the app states that exactly that Play 5 would be “disconnected” - even though its wired and replying to ping…

Thanks for helping me finally sorting this out!


Not every Sonos device can connect to 5GHz, you say you have a Play:5 but don’t specify the others. You also dont specify which frequency the app-running device is using.

Many routers have trouble passing data between 2.4 and 5GHz devices, and this will causes devices to drop-off the app (though in fact they are still on the network just fine).

You also seem to have a heath-robinson arrangement of other network devices, any of which could also be blocking the SSDP packets necessary to keep contact alive between devices.


Ah, yes, sorry. In total its

  • 2x Play:5
  • 2x Sonos One
  • 1x Sonos One SL
  • 1x Sub
  • 3x Sonos Roam
  • 1x Sonos Roam SL

And all devices are on 5Ghz - they couldn’t connect to 2,4 even if they wanted to, because that is another SSID they are not configured for! And I would describe the network as pretty much standard? A wired backbone from a central location and Access Points at each end. In theory nothing should interfere with the packets, since everything is on the same subnet and Deco doesn’t even filter out broadcasts. Honestly: The traffic shouldn’t even pass through the switches/the router, since everything Sonos-related should happen on only one BE85 (they do have physical ports which I used to hook up the Play:5 for testing). I will look into SSDP traffic however since multicast always is a difficult topic and I cannot rule out that TP-Link is doing some unwanted “optimization” here…

Oh - and one more thing to add: My Windows PC which is also wired to the central switch picks up all the Sonos devices as possible UPNP Clients - pretty sure this is happening over the multicast accouncement...


From the FAQ:

https://support.sonos.com/en-us/article/supported-wifi-modes-and-security-standards-for-sonos-products

https://support.sonos.com/en-us/article/understanding-the-network-details-section-in-the-sonos-app

https://support.sonos.com/en-us/article/recommended-settings-for-using-sonos-on-wireless-networks

Once you have set DHCP reservations for your Sonos you need to power down all Sonos and your router. Power up the router, then the Sonos which will clear any stale IP address assignments.

I’m not a fan of Sonos on 5 GHz due to the reduced range but if the 2.4 GHz spectrum is too noisy it may be a superior option. The network details might help sport that out.

Since you aren’t using it, it isn’t your problem but your channel 4 selection is usually iffy as it overlaps BOTH channel one and six. Almost always better to stick to the non-overlapping one, six or eleven channels. Sonos also seems happier with a 20 MHz bandwidth on 2.4 GHz, not sure what it likes on 5 GHz.

I was surprised to see this at the last link above, I thought Sonos preferred static 2.4 GHz channels.

For 2.4GHz, enable auto channel selection. Your router will select the best available channel for all connected devices. This is recommended for wireless setups only.

As here says: https://support.sonos.com/en-us/article/change-your-router-s-wireless-channel

Find the wireless settings page and change the wireless channel for the 2.4GHz network. If “Auto” channel is enabled, make sure to disable it and set a specific channel. We recommend using channels 1, 6, or 11.

 

Can you see things like “Channel Utilization” and “RF Noise” in your AP’s information? I’ve found that some channels that look like good options on a WiFi analyzer are actually poor choices when the non-WiFi signals are also considered.

 

 


The issue was indeed with the SSDP packets. I wasn’t aware Sonos heavily relies on multicast.

This is not a problem for very small networks. Its also not a problem for very big networks (given they are managed well). However, if you are running a medium sized network in your home (~100 total clients, some on wifi, some wired, backbone with several switches + mesh wifi) its typically bad news because it will typically flood the network. Luckily I recently bought new managed switches that come with support for IGMP snooping, After I enabled the feature and setup my primary switch as querier the discovery issues were gone. Its a night and day difference - the app now instantly has all devices listed every time with no delay whatsoever.


The issue was indeed with the SSDP packets. I wasn’t aware Sonos heavily relies on multicast.

This is not a problem for very small networks. Its also not a problem for very big networks (given they are managed well). However, if you are running a medium sized network in your home (~100 total clients, some on wifi, some wired, backbone with several switches + mesh wifi) its typically bad news because it will typically flood the network. Luckily I recently bought new managed switches that come with support for IGMP snooping, After I enabled the feature and setup my primary switch as querier the discovery issues were gone. Its a night and day difference - the app now instantly has all devices listed every time with no delay whatsoever.

SSDP is how devices are tracked: if a device keeps responding to the SSDP discovery call every X minutes (I forget what X is) then its all good, but if the SSDP doesn’t show up then the app will mark the device with the red dot in the app. Also if you power down a device, the other Sonos devices will soon notice its absence and issue an SSDP “byebye” message to inform everyone of the situation. Ditto if you power one up the others will notice and rebuild the topology and send a fresh SSDP “alive” notification.

SSDP is sent via both Broadcast and Multicast, I assume to handle the most router types.


I guess I was a bit too quick on that. After running perfectly for one day (discovery and real streaming) its now back to how it was before. No changes on my side - just noticed it when I tried to start watching TV last night and there was no sound (TV is hooked up to the stereo input of one of the Play:5). Tried to check with the app - half the speakers gone again :(

IGMP snooping is still active and I can see in the switch frontend that it actually does do something. I also see that there are way more multicast packets passing the switch then unicast - which seems a bit odd. I guess its some packet sniffing next...