Skip to main content
IanJShaw
Chromatic Producer I
Jul 17, 2025 11:15 AM UTC

Is the Sonos ecology just too diverse now?

So, many months on from that event and my Sonos system is still best described as “quirky and unreliable”.

 

I won’t produce yet another list of things that go wrong, there’s plenty on here already.  But every time I open the app now I routinely expect, and get:

 - players refusing to join an existing group “try again later”

 - the app refusing to control an existing group

 - music taking up to 30s to start playing across a group of players (I fondly remember the days when I heard the beginning of the first track in a playlist)

 - etc.

 

All of these are resolved with patience and the digital equivalent of “jiggle it about and try again”.  And I usually manage to have a working system that plays my music within about 5-10 minutes of frustration and annoyance at the beginning of every session of playing music.  I’ve come to expect it now.

 

But I’m wondering if one of the problems is that I’ve now got over 20 different players, of pretty much every S2 compatible type, which spans several generations of technology.  Am I really trying to get hardware to work together seamlessly that, frankly, just isn’t up to the job?

 

Now, I know there would be a huge backlash if Sonos came clean and said something like:

“Hands up.  If you really want a responsive, controllable, reliable system then don’t mix products between generations.  So, for example, never expect a Era 100 to play nicely with a first generation Sonos One, they just aren’t fully compatible”.

 

But, given that I have got used to there being some “problem” players in my setup and am almost coming to this conclusion myself, might it not be preferable to the current fiction where we’re told everything “should” or “will” work together and constantly being disappointed?

This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

58 replies

Stanley_4
Grand Maestro
Jul 18, 2025 3:51 PM UTC

As I don't use dnsmasq these days that doesn't apply to or interest me.

As doing the static mapping fixes the issue (if present) and allowing the DHCP server to assign them (regardless of how they are derived) doesn't, well I guess I'm missing how any of that matters to a Sonos owner that is seeing, or possibly seeing, the addressing issue and wants it to work, not a lesson on network utilities operation.

Translate
Local Superstar
Jul 18, 2025 4:18 PM UTC

As I don't use dnsmasq these days that doesn't apply to or interest me.

What router are you currently using?

It will apply to most consumer routers, and you also said you saw “random IP assignments”, that is because you were using router(s) that use dnsmaq (even though you thought it didn't apply).

My point is the vast majority of Sonos users are using consumer grade (probably ISP supplied) routers. Those routers are built using dnsmasq. hidden from the user with a fancy Web GUI or App to manage the router.

Of course the consumers don’t care and have no interest its using dnsmasq, they wont even know what an IP address is, they probably have never logged onto the router,  why should they.

I agree there is no harm, except for HT systems and HT bonded devices, but I am struggling to understand why it is still often recommended.

I’m just trying to debunk this ‘myth’ on forum I keep seeing they should reserve DHCP IP address if they have issues with Sonos system. I have yet to see a valid explanation why this resolves issues with Sonos.

Translate
buzz
Grand Maestro
Jul 18, 2025 4:58 PM UTC

In the past I’ve had issues with duplicate addresses. They don’t always strike and most often appeared after a SONOS update. Duplicates can be exacerbating because they will often “heal” after the address is renewed.

Translate
Stanley_4
Grand Maestro
Jul 19, 2025 12:10 AM UTC

Current routers are Netgate, 3100 and 1100.

 My routers do not use dnsmasq, that is very clear from a simple look at the documentation or even looking at the user interface. Of the DHCP options abailable I currently am using ISC DHCP.

I see no issues from the assigned IP addresses with any of my four HT setups. What are you seeing as a problem?

Feel free to debunk away, but you are facing a difficult problem here. My system has major issues at reboot time without them set and no issues with them set. How you can debunk that will be interesting to see.

Translate
Local Superstar
Jul 19, 2025 7:14 AM UTC

. My system has major issues at reboot time without them set and no issues with them set. How you can debunk that will be interesting to see.

I am not that familiar with pfSense/Netgate, but possibly issue with specific configuration in this setup. Maybe pfBlocker as it tries to update DNS and times out, setting DHCP reservation will bypass this DNS registration. During an update, all your Sonos devices are rebooting at same time, and will require DNS to function, this issue is compounded.

https://www.reddit.com/r/pfBlockerNG/comments/bs9zn6/psa_using_pfsense_with_pfblockerng_and_dhcp/

Apologies to everyone, this has gone a bit off topic, but its interesting (for me, maybe others) to understand why the DHCP reservation is so often recommended by some users of forum.

Translate
Local Superstar
Jul 19, 2025 7:41 AM UTC

I see no issues from the assigned IP addresses with any of my four HT setups. What are you seeing as a problem?

Lets say a user reserves the IP address of a Sub or speaker before its bonded, it will be reserved against the MAC address of the speaker. When it is bonded it is proxied through the soundbar, the same IP will use the MAC address of the soundbar, and will probably fail.

https://docs.netgate.com/pfsense/en/latest/troubleshooting/logs-arp-moved.html

Sone firewalls/routers may also detect ARP spoofing, that is why I would refrain from DHCP reservation of HT speakers.

Translate
Mr. T
Jul 19, 2025 8:05 AM UTC

Lets say a user reserves the IP address of a Sub or speaker before its bonded, it will be reserved against the MAC address of the speaker. When it is bonded it is proxied through the soundbar, the same IP will use the MAC address of the soundbar, and will probably fail.

https://docs.netgate.com/pfsense/en/latest/troubleshooting/logs-arp-moved.html

Sone firewalls/routers may also detect ARP spoofing, that is why I would refrain from DHCP reservation of HT speakers.

Can you point to one thread here where the bonding of a Sub or surrounds failed due to having a reserved IP address before being bonded?

Translate
Mr. T
Jul 19, 2025 8:30 AM UTC

So one example from 7yrs ago. Doesn’t appear to be a major issue that you’re implying it to be.

Translate
Local Superstar
Jul 19, 2025 8:53 AM UTC

So one example from 7yrs ago. Doesn’t appear to be a major issue that you’re implying it to be.

 

Maybe this thread could be another example you asked for, as it appears OP has reserved IP addresses?

I have never said its a major issue, as the vast majority of Sonos users do not reserve IPs in DHCP, and they have fully functioning systems. If it was a major issue, Sonos would recommend it.

Some users have very unique/specific home network setups with ‘boutique’ type firewalls in a home setup, and may have a work around using reservations, but it does not apply to the majority of Sonos users.

All I’m asking is an open mind, just because something has been recommended in past by a few users with very specific network setups, does not mean it should be the default recommendation today.

Translate