Thanks @Florent for the prompt investigation and instructions for a workaround.
You mentioned that the DLNA issue had been fixed, did that include allowing the required Service ID's for Sonos DLNA I had mentioned two messages ago?
I upgraded to 2.0.1 and unfortunately things still do not work like they did in 1.4.1.
It sounds like maybe none of the mDNS/Bonjour fixes were implemented yet? I'm beginning to wonder if Sonos hasn't made, or started to make the transition away from DLNA discovery, to mDNS/Bonjour discovery? I think tomorrow I will contact Sonos support and see if they have any insights they can provide.
My apologies if I'm stating the obvious here, but Sonos has two modes you can connect their speakers in:
WM=0 mode which is Sonosnet, you connect 1 speaker or a Sonos Boost or Bridge to ethernet and it will form a proprietary wireless mesh for only Sonos speakers, they don't use the Aruba wifi for the speakers but you may have your controller device (phone, laptop, etc. ) on the Aruba wifi.
WM=1 mode which is wifi, the speakers connect to the Aruba wifi network as clients. The Sonos Move portable speaker can only run in WM=1 mode, it is unable to connect as WM=0 and belong to Sonosnet. You controller devices (phone, laptop, etc.) would be on the same wifi network as the speakers, the Aruba wifi.
In pre-2.0.0 I was running my system in WM=1 where the speakers were using my Aruba wifi as clients but I believe in pre-2.0.0 there was no multicast/broadcast filtering taking place and no Airgroup running (Shared Services). Everything worked fine.
After upgrading to 2.0.0, I lost visibility to all the speakers that were connected to the Aruba AP in WM=1, they were still connected on the wifi network but now because of filtering, the Sonos discovery protocols where being blocked. I removed them off my wifi and set them up to run in WM=0 mode, and they became visible again to my Sonos app. Unfortunately, the Sonos Move doesn't support WM=0 and since upgrading to 2.0.0 I am unable to use it at all.
I guess if you eventually enable mDNS/Bonjour for _sonos._tcp and it starts working again then we will know if they've started to depreciate the DLNA discovery but, none the less, I will still contact Sonos support and see what they have to say.
I think enabling the _spotify-connect._tcp m DNS/Bonjour will fix the direct play for the Sonos players there, I tried your workaround but it didn't work for me.
Thanks again for looking into this. I have a ticket open with support and they are still investigating as I have other issues related to the addition of Shared Services.
You're welcome @Florent, no worries, I'm sure we'll get this all figured out eventually.
My wallet pains me to say this, but I have at least 1 of the following Sonos models:
I don't currently have the Play:5 (gen2), Connect (gen2), or Port connected at the moment.
When I was researching what discovery protocols where in use, it appeared that the newer products were using both sonos and spotify-connect mDNS/Bonjour whereas the older products like Connect:AMP where only broadcasting spotify-connect mDNS/Bonjour.
Hey @Florent ,
I fired up Wireshark and did some packet sniffing this afternoon, I was connected wirelessly to the SSID tagged to VLAN 201, VLAN 201 is where my clients and most of the media devices reside, either wired or wirelessly.
I can see mDNS requests for Spotify Connect and replies from some of my Sonos players (via the Aruba AP Airgroup / Shared Services service), it’s a mixed bag of my Sonos players on who replies: some old players, some new players, some on wired on ethernet, some on Sonosnet wireless (these on Sonosnet would appear as wired devices to the Aruba AP)., that would actually mean that all my Sonos would appear as wired clients as they are in WM=0 mode (sonosnet) as I can't get them to work on the Aruba wifi as clients in WM=1 mode.
I can see SSDP requests from clients and replies from my Sonos players (via the Aruba AP) as well but I believe that Sonos also uses other broadcast traffic for speaker setup, etc. I will try and sniff this traffic at a later date.
When I open the Sonos app on my MBP, I can see in Wireshark that it does a SSDP search to:
And then Aruba AP returns a pile of responses with all the Sonos players on the network that have that Service ID. So that one part appears to work. I can’t tell whether AP is also communicating the other DLNA/SSDP Service ID’s that Sonos uses.
I haven’t seen any _sonos._tcp requests or replies being made on the wireless, so I don’t know how those fit in. Haven’t had chance to contact Sonos support yet to see if they can provide any insight.
I did however see the AP query for a long list of mDNS services, and those did include:
I’m also having issues with SSDP and the DIAL protocol. I have two Nvidia Shield 2019 on my network, one is connected via ethernet, one is connected via wifi, both on the same VLAN.
When I go to cast on my Android Pixel 3a phone in apps that use DIAL (Netflix):
-Shield on wifi —> not visible
-Shield on ethernet — > visible
Same in Chrome on MacOS which also uses DIAL. The mDNS (googlecast) on both Shields seem to work okay.
So I also fired up Wireshark on the wired side of VLAN 201, my Windows 10 PC, and saw something interesting, the Aruba Airgroup / Shared Services service does NOT send out queries for mDNS or DLNA/SSDP services down the wire, it appears it just listens to what is on the wire. When I opened up my Spotify on the wired side of VLAN201, then all my Sonos speakers, which reside on wired side, appeared on the wireless side of VLAN201 as all the Sonos speakers send out a mDNS response for the Spotify Connect mDNS request and the AP picked that up and must have put in it’s cache. There are strange things happening with Airgroup/Shared Services with VLAN’s as the AP isn’t keeping services confined to their respective VLAN even when the service isn’t checked to be shared. I have a ticket open for this already.
I had mentioned earlier that my MBP couldn’t see all my Sonos airplay targets, it appears that the MBP isn’t doing mDNS requests for airplay targets so that’s possibly an Apple issue? I do the see the Aruba AP querying for airplay services but only on the wireless side and I have clients on the wired side but they never see the request from the wireless clients. I don’t know if maybe the MBP is expecting unsolicited advertisements of the Airplay servers as well? Again, these don’t appear to be making it through from the wired side for some reason.
I’m like to spend more time on this but I’ll have to save it for another day.
Same problem here, 5x AP11 with version 2.0.1. All speakers gone. Its random, after the update it worked for about 4 hours then speakers disapeared. Now my kitches speakers (2x Play:1) still play the music it was tuned to but the sonos app doenst see them anymore, looks like it connect through SonosNet now. Play:1 in my backyard only works with LAN connection and appers in the Sonos app if i do so.
Its frustrating that Aruba apperantly does a poor testing and uses its userbase as alfa/betatesters. This issue was with 1.3 also but solved with 1.4 and now its back. I wish i had choosen Ubiquity as I first planned. I thought Aruba had more experiance but I was clearly wrong.
I am not using Sonos, but Sonoff (rather similar name, different purpose). I am using home automation called "home-assistant' and it has been controlling my smart switches (or relays, if you please) for a while now, using this plugin: https://github.com/AlexxIT/SonoffLAN
It is using multicast, and since I am not sure if my AP12 devices (four of them) had version 2.0.0 or just skipped directly to 2.0.1, I cannot tell if there is a regression with 2.0.1 behaviour comparing to 2.0.0. However - comparing to past versions, there is no doubt that there has been a regression. Multicast is being cut off, which prevents my switches from working. The GUI does not allow configuring anything about it.
I have made sure my backbone switch (old Cisco 2960) has IGMP snoop disabled, so no throttling here. Just the switches. This is very frustrating. If anyone from HPE is reading this - please release a fix soon, with the option to enable/disable unfiltered multicast.
I'm experiencing problems with AirPrint on a Brother printer that resides on a different VLAN than the one that my SSID is bridged into.
I suspect it is because multicast filtering is enabled. I have confirmed that the printer is checked off within Shared Services. A ticket has been opened.
Between this and seeing large latency/jitter/packet loss on my APs (separate ticket open with no resolution in sight), I'm very disappointed in this ION setup, I should've stuck with Ubiquiti.
Thank you for your feedback. We have made several improvements to the Shared Services feature in Instant On 2.0 software release. However, since there are multiple deployment combinations and multiple models of Sonos devices, we are aware of some these use cases that are not working. We are actively investigating them to find a fix. We will release a new software to address it. Appreciate your patience. If there are any other issues you are facing, please reach out to Instant On support.
Dear @Florent ,
I can confirm that DLNA still does not work in 2.0.1. I am using a minidlna server running on the network and none of the wireless clients connected through AP11 are able to see it. Any client reaching the server from wired connection works perfectly.
I can also confirm what others experienced about airprint. It is not working 100%, some of the clients can see the Samsung printer on the network, others not.
There is also a problem with Chromecast audio clients. They frequently just disappear from the network.
One additional strange thing. I upgraded to 2.0.1 the day it came out. Since then the installation date changed 2 times on the AP while firmware version remained the same. Now it tells me I installed the actual firmware 2 days ago, which is for sure not the case. What is also strange that I have no update schedule on Sundays, so either 2.0.1 was pushed again to the device as a critical update or I do not understand what happened.