Question

10.6 update broke IGMP on OSX

  • 23 December 2019
  • 11 replies
  • 692 views
S
Userlevel 1
Badge +2

I have a sonos on a dedicated IOT subnet and things have been fine with both OSX and Android controllers up until the most recent update.  Now, only Android controllers work and OSX controllers are failing to see the IGMP messages.

 

While I understand that Sonos does not support cross subnet setups, it would be great if Sonos could take steps to avoid breaking this scenario for people like me who had things working fine.

 

Please unbreak OSX controllers so that IGMP works fine with them again across subnets as it did before, and as it still does for Android.

 

I’m left as a customer wondering if I can trust any future updates, which is a bad feeling. 

 

Please note that I am not requesting Sonos help with network configuration, and I understand that Sonos does not offer that, nor do I require it.   I am only asking Sonos to undo whatever broke this scenario for the last OSX update.

 

 

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.

11 replies

ratty

Implicit in your post is an acknowledgment that yours is an unsupported configuration. In recent times Sonos have taken various steps to improve the security of the system, including preventing access to port 1400 from off-subnet sources. It could be that the latest developments are a corollary of those increased security measures. 

S
Userlevel 1
Badge +2

Hi Ratty!

 

I am not asking for support with this configuration =)  So no problem there.

 

The configuration is fine and has worked for myself and other customers for some time now.

 

If we were asking for support, as you suggested, then I could see how you might have a very small point to make.

 

Sonos should be careful about messaging that crossing subnets is an abnormal practice.  It’s a common practice, and when Sonos acts unsure about it, it makes them seem uninformed.

 

Sonos should simply acknowledge that they broke this setup for OSX users, get the message to their techs so they can immediately inform customers who ask, and fix their mistake.

 

S
Userlevel 1
Badge +2

If any kind employees from Sonos are reading, here are some other customers also having a bad time right now after the 10.6 update.

 

These customers have done nothing wrong, and are not asking for networking support.  They just want what worked before to keep on working.

 

https://en.community.sonos.com/setting-up-sonos-228990/vlan-issue-on-unifi-network-after-10-6-update-on-ios-6833871/index2.html#post16384544

https://en.community.sonos.com/announcements-228985/sonos-10-6-now-available-6832438/index2.html#post16384545

https://en.community.sonos.com/ask-a-question-228987/sonos-control-across-a-vlan-has-stopped-working-6833843#post16384547

 

Airgetlam

Similar to how the Apple update to iOS broke the ability to play from an iOS device, I would assume that if this change was indeed security related, and not just an intentional gimping, you’re unlikely to have it changed back. And in my years here, I have never seen Sonos make any explicit declaration of what security measures have been taken. 

Bruce
S
Userlevel 1
Badge +2

Here is why I don’t think this was intentional.

 

The IOT vendor, in this case Sonos, would be making an assumption that 2 subnets are not supposed to talk to one another.

 

That decision would only make sense if the IOT vendor had some information about the network to decide that this traffic was unsafe.

 

Since the IOT vendor here has no knowledge of the customer network, it is not reasonable to make an assumption that traffic between subnets should be considered unsafe.

 

The IOT vendor should only assume that the owner of the network did in fact intend for subnets to communicate, because it has no information to contradict that assumption.

 

 

S
Userlevel 1
Badge +2

Also, if it were the intent of Sonos to intentionally break the setups of customers, it seems like that would be a consistent decision across platforms.

 

And yet, non iOS controllers are still chugging along without this issue, suggesting that Sonos did not intend to make our systems fail under these circumstances.

 

P
Userlevel 1
Badge

Having the same problem here and I am really angry that Sonos not even commit they changed something.

Also, if it really is for security reasons, why not just support using the product on different subnets or even „allow“ it? This is the most secure solution in which all other proprietary security measures well fit. The more IoT devices this world gets the more possible security threads could appear...

L

In the tech world this is called a REGRESSION.  A customer use model used to work, then Sonos changed something, and now it does not work. A customer oriented company would react to this as, “ Oh no, we broke something!”

Maybe the breakage was unintentional and there is an easy way to get it working again.  Or an easy work around.

Or Sonos can say sorry, buy someone else’s products from now on.

 

controlav
Userlevel 7
Badge +23

Its not a regression if it is an unsupported configuration and only worked by accident in the past.

If a customer is technically savvy enough to figure out how to get it to work across VLANs, then that person should be able to figure out exactly which packet(s) are not making it across the LANs any more, and provide a solid description of the problem. The best theory I saw was the TTL value changing, but as I’ve never tried cross-LAN connectivity I cannot confirm.

SSDP is not a complicated protocol, but to work between LANs a bunch of configuration is required that is very specific to the network hardware in use. A quick web search hit this as an example: https://help.airtame.com/en/articles/1257772-step-4-set-up-auto-discovery-multicast-routing-between-vlans

Author of the leading independent Sonos app for Windows, the only Sonos app for Xbox, and a Sonos app for iOS
A
Userlevel 2
Badge

Looks like it’s not the TTL that is the issue but the Sonos kit now responding on random high UDP port numbers.  I’ve updated my original post at VLAN Issue on Unifi Network

inopinatus
Userlevel 4

The real problem here is that Sonos’s release notes are fisher-price tripe, and what that says about them as a company.

 

Contrast point. I just got an update for one (1) of the many network appliances I manage at work. It’s not even one of the big core network routers, it’s just an edge device costing the same as a Sonos 5.1 system. Nonetheless, the release notes are 132 pages long, and go into extraordinary detail about every technical change they made, irrespective of whether the configurations that they enable are supported or not.

 

The equivalent release notes from Sonos:

“Bug fixes”
“Improved menu”

 

Then it turns out they made significant changes to the network stack, DSP behaviour, voice assistant integration &c.

Do they want to ship high-end gear to sophisticated consumers, or do they want to sell tamagotchi to schoolchildren?

My takeaway: Sonos’s engineers think we are all idiots, and you just need to read this thread to see multiple apologists for that lousy attitude.

Given recent events, it appears their marketing/PR people have the same haha-screw-you-suckers attitude, so I guess it’s just their entire corporate culture that sucks.

 

uncooked meat prior to state vector collapse
Terms & ConditionsCookie settings