Apple Homepod has great sound and works well. I really do not have time to mess around with trying to fix what Sonos broke, I simply want to play music on my spearkers using my phone, which is something I now can’t do. Extremely frustrated.

On consumer level equipment it’s unlikely they would treat them as different. Wifi routers may have an option to change the multicast bandwidth or convert multicast traffic to unicast, but they are unlikely to fine grain filter or block individual addresses in the multicast range out the box. The IoT industry would be dead in the water if that was the case as they generally use mDNS.

The mDNS address sits within the IP Multicast reserved address range maintained by IANA. Addresses within the range are allocated for defined uses. Very few consumers are likely to even know such a list exists nevermind know the range or care. You’d be surprised how few developers actually know about rfcs and iana allocations even when developing things that must operate within the globally defined specification. In the av field upnp/dlna is an example of implementation vs specification causing interoperability issues upnp/dlna was designed to prevent.

If someone is using “prosumer” or enterprise equipment, without understanding what they are configuring and blindly following random internet advice, then sure incorrectly configured equipment could come into it, but that would most like be minority cases in the consumer market and they would have more than just mDNS issues over the time they own the equipment.

Most of the posts I’ve seen citing the change as a cause, suggest limited understanding of what mDNS is or how it operates, provide no reason why it should impact and unfortunately fit the usual “blame the users network first” tone. ie, something involving networks changed ergo it must be the users local network because mine works fine.

Something worth keeping in mind, on a daily basis there are more people globally using mDNS, without knowing it exists, than there are registered Sonos products (Based on the 2023 Q4 report). If anything changing to mDNS should make local discovery more reliable because it runs on a reserved IP multicast control address dedicated for use by mDNS.

The initial standard was proposed in 2000 and finalised and publish as an official rfc in 2013, heavily influenced by the Apple bonjour implementation

Apple have been using it since 2002 in their products and software regardless of OS, iTunes for Windows for example, would install it long before Microsoft got around to adding it.
Linux (Avahi) since 2005
The vast ocean of ever increasing IoT devices started using it back in 2013.
Microsoft added it to Windows 10 in 2017.
Google finally got around to adding it to Android in 2019.

I think it was very unlikely to have been a well supported and unanimous decision within Sonos to perform the release. While there are obvious and widespread effects to Sonos customers and potential future sales, I expect there will also be some long lasting effects internally as individuals at Sonos assess their own situation and make decisions accordingly, which will also have a knock on effect to future development and support. Unfortunately I doubt it will be a good effect.

There are some notable much larger companies who have a habit of remove entire services and features, not just key functionality, without warning *cough*google, microsoft. Maybe some within Sonos think the company is bigger and more important than it really is. A couple of clients and companies I’ve worked with in the past had no concept of how insignificant they really were in the grand scheme of their service suppliers and would stamp their feet demanding attention believing their brand name or drop in the ocean spend carried some weight.

As customers how much tolerance and patience should we have? Mine lasted until the shambles of the first AMA, at which point it was clear it would be months if ever until feature parity was released and the ceo and senior staff made clear their view and attitude which provided an insight into how they operate the company. I would count in the silent majority as I just got on and replaced everything.

I can understand people getting frustrated and wanting an outlet to vent, but I do think people will often go to over the top, sometimes abusive/rude, extremes and knee jerk reactions online, thinking they are hidden behind the anonymity of a keyboard. If you look across forums and online, there are definitely some cultural differences in online behaviour and how people express things when they don’t like something. There has been an increase in unnecessary behaviour over the years and in general had a huge uptick during covid. I can’t even fathom the behaviour of people and nastiness during covid.

Anything I say online or across electronic communication is the same thing I’d say if the person was stood in front of me. Just because it’s online communication doesn’t change that.

It is interesting the different things people find key critical to be missing. Out of everything, regardless of whether I used it or not, the oddest thing missing on release in my opinion was the ability to change/update wifi settings in a wifi speaker.

Great mDNS post, @sigh. One thing you didn’t mention is the relative newness of mDNS in Sonos firmware. There may be exceptions/corner cases in the mDNS code that have not yet been ironed out.

Totally unrelated to Sonos, I recently came across such an issue in the avahi daemon (the service that handles mDNS on Linux) that manifested itself only once or twice per day.

If such an snafu exists in the Sonos firmware, hopefully it will be diagnosed and fixed at some point.

Absolutely, there could be edge cases in the player and controller devices, some of which could be difficult to test or don’t show up in the pre-release testing due to the time it takes to manifest.

I don’t think Sonos are recent newcomers to mDNS and I think it has actually been on the players for quite a while. I’m not sure when Sonos added mDNS into the firmwares as a permanently running service, unfortunately the early interest in the Sonos hacking community seems to have died off, so firmwares to peek inside are few and far between.

Trying to find the gpl/lgpl downloads after 14.18 is difficult, but in theory they should provide them if asked, which would almost certainly show when they started added the package.

From firmwares I’ve seen, it appears mdnsd was in the 2017 34.16-37101 and in the 2022 57.10-25140 fenway S1 firmware, so no reason to think it wouldn’t be in the S2 firmware as well. I’d even hazard a guess that the main difference between the S1 & S2 firmware is the Sonos application and a value written into the manufacturer device page when choosing to upgrade/downgrade between S1/S2.

In 34.16 it looks like it had a specific use case in a certain wifi mode, but it’s also possible the Sonos application called it’s run script.

In 57.10 the mdnsd service was started by the main inittab script, along with the Sonos application and a Control4 discovery service.

Whilst mDNS/Bonjour have been around for a while, there appears to be plenty of instances for various home networking gear where handling of these packets doesn’t work as expected… things like works on wired, but not wireless from the same router etc. 

I wonder if many of the people with bigger issues have inadvertently created networks with simple switches here and there that are not handling this correctly… One potential tweak could be to make sure all Sonos device access is via one switch/router and see if that helps improve matters? 

Most IoT stuff tends to be wireless, or uses some kind of wired hub, which may end up being on a ‘core’ switch by default in most cases if people just plug them into the back of their ISP router for example. 

Also how many people who have plugged in a Sonos device (as I did) have inadvertently created a SonosNet system, and then are Sonos themselves correctly relaying mDNS between the primary network and SonosNet? If you then have a mix of newer Sonos components like Era’s or Moves and older stuff are they isolated? Does getting rid of SonosNet improve stuff? I had SonosNet by accident and since recently getting rid of it, responsiveness of the new app has improved quite a bit, and I have a Sonos Move device which as I understand it, can’t use SonosNet…

Also on controller devices, do people have firewall software that is getting in the way? You’d hope that most up to date stuff would allow mDNS but would for example oder ISP routers with built in firewalls be up to date? Are local home networks correctly defined as ‘trusted’ so more stuff is opened by default? 

Then do things like MAC private address generation for privacy start to get in the way as each time you connect you get a different MAC address? Should you make sure that stuff is turned off for your home wifi if you use your phone/tablet as a Sonos control point? 

In theory much of this should work, but it also seems that using reserved, fixed IP’s for Sonos has benefits even though in theory it should not… 

Multicast and wireless definitely has some quirks and limitations, regardless of what protocol is going across it, especially as the amount of multicast traffic increases. A network with very “chatty” devices can impact wifi performance, unless the wifi access point is configured correctly, eg to convert multicast to unicast and/or enable wifi client isolation.

This often shows up in larger environments where you have many wireless clients per access point. The access point can spend so much airtime forwarding multicast packets it impacts general wifi performance. There is no hard and fast rule about when the impact occurs and the onus is on the people responsible for the network to configure devices appropriately.

It may also be out of the box a device has wifi client isolation enabled, as the target use is for wireless access to the lan or internet and not wifi to wifi. In general the ability to enable/disable isolation is also exposed in the device interface.

Definitely, that could be a useful troubleshooting step when people have more than one switch/router in the mix.

I have an old (2008) Cisco branded small business switch, which is actually Linksys software, from when Cisco bought Linksys. It’s software is a bit of a buggy mess. Even though it is managed and supports igmp snooping, vlans, link lagging etc… trying to get ssdp (upnp/dlna discovery) multicast passing in and out of it reliably is pointless. Plug everything directly into it and it works like a charm.

mDNS with the ikea smart hub and my network - zigbee gateway had no issues at all.

It’s as though the switch software was happy with the defined addresses in the multicast control range addresses, but the general reserved admin organization range which is where sspd sits was problematic.

Spread everything back across the 3 switches and it’s like having a split network with the Cisco living in it’s own little world. 

The majority of IoT hubs use mDNS for the controller app to hub discovery. Some have an additional online broker as fallback and some only use an online broker/api.

The Philips Hue hub for example uses mDNS for local discovery as the primary method and an online broker to supplement it. A requirement for 3rd party approved controllers is automatic discovery and you wouldn’t want hub discovery to rely on only the internet broker/api. The bulbs themselves use zigbee, which despite the increased production costs, has it’s own benefits.

Early Tado smart radiator thermostats were wifi and online broker/api only. It wasn’t possible to control the devices from phone/tablet if your internet went offline, you had to resort to pushing buttons on the thermostats without internet.

Sonos have sensibly used local discovery with internet broker/api to supplement it.

From a manufacturer development perspective, DNS-SD (a complementary technology) can simplify the discovery process used by applications and developers. It would allow developers to just use dns requests in the app for both local mDNS and additional internet broker requests, if the online broker uses dns to provide the information.

In reality, many will actually use an api based broker because the devices are registered against an online account anyway, the api service has other uses within the app and it can have security restrictions applied.

I’ve done that a few times over the years. Plugged a remote speaker in then forgotten to disable the Wifi on it.  It always ended up unstable and manifested in odd ways. The most obvious was actually music streams from both local and internet would randomly stop. Open the app, restart it and then it would continue before randomly stopping again later.

It can be painful to track down when the Sonos STP doesn’t work and the random behaviour starts. Sometimes devices drop in and out of discovery, sometimes they’re always discovered but music streaming randomly drops out on one or more speakers. To make it even harder to work out, restarting everything in a specific order can appear to restore stability, until the lack of STP control causes it to randomly fall apart again 

The discovery method is irrelevant in this situation and you’d have to be very lucky to not have any issues at all if STP isn’t working.

Unless something has changed in recent firmwares then networking is at the OS level. Wifi and Ethernet are joined to a bridge, joining wifi networks/sonosnet, default gateways and multicast routes are deleted/re-added as the interfaces go up/down or lease IP addresses. The Sonos application in the devices and mdnsd service rely on the underlying network to make the correct decisions about where traffic goes.

My 4 remaining Sonos speakers are still stuck on sonosnet. I could reset them I guess, but when the new app hit I was wanting to remove my port which had been providing sonosnet, but the app had no ability to add a wifi network. One of the speakers not worth selling is currently in the same cupboard/closet as my switches because it was the easiest way to hardwire and keep sonosnet and still remove the port

In general, consumer level routers default to everything inbound from the internal lan allowed, external blocked with lan and wifi treated as internal. ISPs will often add holes to the external side for remote management.

Built in firewall rules for easy restriction usually operate against the lan → wan traffic rather than lan/wifi.

As you move into the more advanced and “prosumer” routers and enterprise equipment, then they can treat the wifi as a separate zone to the lan and require an owner to make changes for a flat internal network.

For someone with a router like that who had a stable Sonos system (so already made any necessary changes) and no discovery issues, a change in discovery method is unlikely to cause an issue, but not impossible.

For a new owner, who has never had a need for wifi → lan communication they’d need to make updates regardless of the protocol

The MAC privacy address generation can have some interesting side effects, but would usually affect more than just Sonos from the device. Whether an owner would notice would depend on the apps they use.

If a network has a small number of addresses available in the dhcp pool and/or long dhcp lease times set, then there is a potential that the dhcp address pool could be exhausted.

On a wifi only tablet, most apps would stop working and it would have trouble connecting to the internet because it can’t obtain an IP address.

On a phone or tablet with cell data, then anything on the wifi side would stop working, but the device would generally fall back to using the mobile network until the wifi is working again. For most mobile/tablet apps it is a non-issue. They connect to internet services so whether it is over wifi or a cell network is irrelevant. For Sonos or any other app that needs to talk to the LAN it would be an issue because there is no working lan connection.

In the UK I’ve seen claims that some ISPs only have a small address pool (~60 ips) with no ability for the user to increase it. It’s not too difficult to imagine a larger household could exhaust that especially if they have many devices with MAC privacy.

MAC privacy is usually a network specific setting, so I disable it on my home & trusted network connections, such as my parents, but leave it on for other networks.

My reason for disabling it was less to do with IP address exhaustion, but more because it was a pain to look through my pi-hole logs and work out which of the devices was having a dns request blocked 

Where a bug in the Sonos firmware or app could react badly is IF a websocket is used between the controller device and the player. There will be a limited number of sockets available in the player. In older firmware the sonos application config had 4 sockets available. IF there was a bug in the player firmware application and IF it didn’t release the socket when the controller disconnected, then a controller could in theory change it’s IP 5 times and be unable to open a websocket.
On the flip side IF the controller device tried to use a websocket that was no longer connected to the player that would cause errors if there wasn’t appropriate logic in the controller app to detect and open a new websocket.

I would consider that an edge case scenario, but it would be very difficult to identify as a user without an appropriate error message.

Websockets provide some different challenges when an application uses one, but can’t reliably detect if it has been disconnected from the remote end. Across the internet to an online service, there are multiple devices which could silently close the websocket connection without informing the client. If the client application can’t detect it and create a new websocket, it sends data down a websocket to nowhere. A platform I worked with had exactly this problem, the cloud provider loadbalancer would silently close websockets without informing our server or client application. Both the servers and clients tried to use a websocket to nowhere, and the library used in the client didn’t handle it very well  Was a tricky one to diagnose and track down as it only happened under a specific set of conditions.

I’d love to be able to have a dig around and see what’s going on inside a network where fixed IPs for Sonos devices actually makes a noticeable difference. The Sonos controller app does not allow adding device IPs so it is going to perform discovery regardless and that can’t be bypassed.

With an old pioneer receiver it was beneficial assigning a static IP and using the IP address in the Pioneer app. Having the IP in the controller app meant it didn’t need to perform any discovery to find the AVR, which also happened to be plugged into the troublesome Cisco switch I previously mentioned 

I have used and do use fixed IPs for some things, but it is usually for my own convenience, rather than it making a difference for discovery. A dhcp network with always on devices, like sonos, tvs, media players, is pretty much static anyway in normal circumstances. Unless the controller app allows adding the IP it’s going to perform discovery anyway.

I fear things have strayed off topic somewhat and maybe discussions should be in their own thread.

While there are many weird and wonderful ways things can break or have difficulty, manufacturers usually have enough tools and ways available to create applications with fallback mechanisms to handle consumer networks. They won’t catch every edge case, combination of black boxes or even be bug free, but generally I think there is enough technology available for companies to use to work around common network issues, which don’t require significant knowledge or intervention by the end user.

As Sonos CEO Patrick Spence promised in his July apology for the company’s lamentable Black Edition app release, updates will be dispatched your way at least every two weeks. And that they have. But none of those updates has done anything material to restore core Sonos functions. I still do not have access to my Sonos-created playlists; neither do I have the ability to create new Sonos playlists or edit queues or do anything else of value with the Sonos app.

So, the burning question is: why update, why remain standing-by for fundament repairs when they do not appear to be Sonos priorities?

Why stick with a company that does not value the consumers at the base of its customer pyramid. You know, the people who have invested money, time and other personal resources in building playlists/song collections in a system they can rely on but do not have the time or technical expertise  to waste in researching how to fix all of the above when the company short-circuits access to those collections?

I’d suggest many of the updates listed here are to ‘core’ functions. Can you please define what you mean by ‘core’?

As individuals who bought into the Sonos ecosystem how long to wait, whether you believe the direction of Sonos fits your needs, having the ability to use your devices being outside of your control and whether they will deliver what you want is an individual decision.

People who spent more money on Sonos products will generally wait longer because the cost to replace is higher for them.

People who have had Sonos a long time may see this as a bump in the road that will eventually be sorted. It’s not the first time Sonos have messed up, but it is the worst they have messed up. I’d say the S1/S2 was bad but intervention and a back down by Sonos prevented that being worst than the current situation.

People who have minor or no issues will just carry on as normal.

My decision to replace my whole house system was confirmed after the AMA. I am fortunate to be in a position where I can do that and in reality the most expensive part of my new system, the HT AVR and speakers, I already owned and they were never going to be a Sonos soundbar setup.

My personal reasons were:

- seeing the gulf between the new app and its limited features vs the old app it was obvious it was never going to be a quick fix

- the public statements and the attitude of the senior team at the shambles of an AMA doesn’t align with my view of a company/division run by people passionate about music or people who use their products. Similarly there is a car brand I will never buy no matter how good the cars might become because of their current senior leadership.

- I had already been biding my time watching alternatives because I wasn’t 100% comfortable with the software dependency outside of my control. The same concern exists for Amazon and Apple products, amongst others.

I’m not sure what the 20-30 million to fix things is disappearing into to. Or maybe that is an expected cost to business figure, taking into account delayed product launches and things. Maybe the board member being drafted in is being paid a consultancy fee. It is an awful lot of money to add call centre support staff and few software projects can be fixed by just throwing more developers who don’t know the code at it.

How long should you wait to see if Sonos will have the system providing what you want is a decision only you can make.