I updated to today’s device update (82.2-59204) but still Airplay is broken to my ERA100’s and continues to work to my Arc. Other services continue to work to the ERA100’s so it just seems to be Airplay affected again.

Has anyone had any joy with this update please?

Just registered to say thank you for your profound investigation

The latest firmware update apparently has now allowed the desktop app to be able to find my system when I’m on my main VLAN. Previously, I had to be on the IoT VLAN for the desktop app to see it. Reading what tim_p wrote, that explains maybe why my I’m unable to Airplay to the Arc Ultra as that is newer hardware.

Here’s my theory: Sonos intentionally broke AirPlay over VLAN on the current Era 100 so that they can include it as a feature in the Era 100 Pro.

And the saga continues! I have contacted Sonos technical support.

1 - The phone support connects you with a call center where the people working there can barely hear what you are saying because of the large amount of background noise. It took 50 minutes on hold to finally be connected with a person. I could hear about seven different background conversations, and I had to repeat myself at least three times for every question the support technician asked.

2 - After 30 minutes on the phone where the support technician reads from the support documents you can find online, I finally asked them to escalate the issue to the next level support team. The problem is they had a very old email in their system that I no longer use. I had changed my email address with Sonos over three years ago, but this old email showed up in the support system.

3 - I had to contact Sonos support again through the chat window and update my email address with them that way. The chat system is just a robot - you have to explicitly ask to talk to a person who can then help you.

4 - It has now been over a week, and I have not heard anything from Sonos at all. Not even an acknowledgement that this support ticket exists and that the ticket is in a queue to be looked at.

5 - Contacted the Sonos support chat system again today to ask for a status. They have no idea when it will get looked at, nor do they have any estimate on the timeline.

So I’m in support limbo at the moment. Someone might look at the issue or they might not. Someone might send me an email or they might not.

Sonos might care about customer support, or they might not.

If anyone on the forums here tells you to contact Sonos support, this is what you get to look forward to.

Cheers, and Happy Holiday!

I have an appointment with Level 3 Engineering on Wednesday to discuss this issue.

if you need some more people joining the call, I would be gladly to join as a Network Engineer. 

Thanks for this, and for taking the time to post what you find.

Sonos has taken a nose-dive in customer service ever since they released the “new” app to work with their headphones. It has broken what was existing functionality. I’ve had more hassles than ever with Sonos since then, and I’m STILL running everything on the same VLAN.

I’d also like to move Sonos to an IoT-type VLAN, and I’m really looking forward to whatever you find.

Just finished a great conversation with Mike in engineering. We reviewed tim_p’s debugging write-up and I confirmed that I can see packets going to my Era 100 on ports 319 and 320 but nothing coming back, every other AirPlay device continues to function across VLANs, this used to work before the October update, etc. Also discussed why VLAN support on Sonos devices is necessary for security, especially with the shift to cloud control. Mike understood the issues and will be opening up a bug report.

I will share updates on the progress of the bug report as I receive them.

Great news and thank you for your efforts! Hopefully this also address VLAN issues with the other newer hardware like the Era 300s and Arc Ultra, which is where I’m in.

I bought a new Era 100 hoping to be able to stream music from my Mac Mini like I do to my Gen 1 Play 5.  Strangely, the Sonos app shows the music streaming via AirPlay to the Era 100 but no sound.  I can even control the playback on the Era 100 with the buttons, but no sound…

Returning the Era 100 until this gets fixed. 

Many thanks to those who’ve spent the time with folks in Engineering to get this fixed.

The Era 100 requires S2, and the PLAY:5 gen 1 requires S1, do they not? If so, they’ll never talk to each other. 

To clarify, I’m not asking Era 100 to talk to Play 5.  I’m streaming from the Music App on macOS to several different Airplay speakers - to an Airport Express, to HomePods (2), to the PLAY5 and (I’d hoped) to the Era 100.  

Sadly, the Era 100 shows in the Sonos app that the music is streaming to it but no sound...

You are not streaming Airplay to a Gen 1 Play:5, that’s for sure, as it is way too old for Airplay support.

Following this keenly. I wonder if anyone can confirm if today’s player update has addressed the issue? I won’t have time to test until this weekend as I’ll have to (re)reconfigure my network.

Still can’t Airplay on my Arc Ultra + Era 300s

No Airplay unfortunately  

However it does work over the Sonos app. 
Dont know if this was working before (probably call2home functionality, no direct play towards the speaker)

Yup same here, looking at tcpdumps on my router, the issue is still present

15:19:52.800887 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:53.822932 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:54.871412 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 320 unreachable, length 120
15:19:55.822052 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:56.831136 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80

.15.4 is my Arc Ultra, .14.171 is my iPad

15:19:52.800887 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:53.822932 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:54.871412 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 320 unreachable, length 120
15:19:55.822052 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:56.831136 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80

Can you check the TTL’s of the packets?
 

15:19:52.800887 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:53.822932 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:54.871412 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 320 unreachable, length 120
15:19:55.822052 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80
15:19:56.831136 IP 172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 319 unreachable, length 80

22:31:07.454573 IP (tos 0x0, ttl 254, id 0, offset 0, flags tDF], proto UDP (17), length 104)
    172.27.14.171.320 > 172.27.15.4.320: .no cksum] PTPv2, v1 compat : yes, msg type : announce msg, length : 76, domain : 0, reserved1 : 0, Flags :timescale, unicast], NS correction : 0, sub NS correction : 0, reserved2 : 0, port id : 32826, seq id : 1, control : 5 (Other), log message interval : 254, originTimeStamp : 0 seconds 0 nanoseconds, origin cur utc :37, rsvd : 0, gm priority_1 : 250, gm clock class : 248, gm clock accuracy : 33, gm clock variance : 17258, gm priority_2 : 238, steps removed : 0, time source : 0xa0
22:31:07.454646 IP (tos 0x0, ttl 254, id 0, offset 0, flags tDF], proto UDP (17), length 134)
    172.27.14.171.320 > 172.27.15.4.320: .no cksum] PTPv2, v1 compat : yes, msg type : signalling msg, length : 106, domain : 0, reserved1 : 0, Flags :timescale, unicast], NS correction : 0, sub NS correction : 0, reserved2 : 0, port id : 32826, seq id : 0, control : 5 (Other), log message interval : 128, port identity : 0x0, port id : 0
22:31:07.462227 IP (tos 0xc0, ttl 64, id 6838, offset 0, flags tnone], proto ICMP (1), length 132)
    172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 320 unreachable, length 112
	IP (tos 0x0, ttl 254, id 0, offset 0, flags tDF], proto UDP (17), length 104)
    172.27.14.171.320 > 172.27.15.4.320: .no cksum] PTPv2, v1 compat : yes, msg type : announce msg, length : 76, domain : 0, reserved1 : 0, Flags :timescale, unicast], NS correction : 0, sub NS correction : 0, reserved2 : 0, port id : 32826, seq id : 1, control : 5 (Other), log message interval : 254, originTimeStamp : 0 seconds 0 nanoseconds, origin cur utc :37, rsvd : 0, gm priority_1 : 250, gm clock class : 248, gm clock accuracy : 33, gm clock variance : 17258, gm priority_2 : 238, steps removed : 0, time source : 0xa0
22:31:07.462316 IP (tos 0x0, ttl 63, id 57192, offset 0, flags tDF], proto TCP (6), length 52)
    172.27.14.254.1400 > 172.27.15.4.39546: Flags 5.], cksum 0x4f0e (correct), seq 1, ack 2111, win 496, options 6nop,nop,TS val 2026687229 ecr 4267826555], length 0
22:31:07.462971 IP (tos 0xc0, ttl 64, id 6839, offset 0, flags tnone], proto ICMP (1), length 162)
    172.27.15.4 > 172.27.14.171: ICMP 172.27.15.4 udp port 320 unreachable, length 142
	IP (tos 0x0, ttl 254, id 0, offset 0, flags tDF], proto UDP (17), length 134)
    172.27.14.171.320 > 172.27.15.4.320: .no cksum] PTPv2, v1 compat : yes, msg type : signalling msg, length : 106, domain : 0, reserved1 : 0, Flags :timescale, unicast], NS correction : 0, sub NS correction : 0, reserved2 : 0, port id : 32826, seq id : 0, control : 5 (Other), log message interval : 128, port identity : 0x0, port id : 0

Just piling on, but I am running into the same thing with Unifi VLANs and the Era 100.

Setup:

• Theater → ARC + Sub + 2 One SLs (Grouped, all wireless)
• Office → Era 100 (wireless)
• All Sonos devices are in a VLAN for AirPlay devices (Connected over 2.4ghz on a dedicated IoT wifi)
• Personal devices are in a VLAN for users (Connected on a 2.4ghz/5ghz on a dedicated home wifi)
• Guest VLAN for visitors  (Connected on a 2.4ghz/5ghz on a dedicated guest wifi)
• Home/Guest users can initiate traffic with the Sonos VLAN and it is allowed to return traffic only

Why? So I can share AirPlay devices with different people in the house, as well as protect myself from Sonos interrogating my network and collecting more data than necessary.

No matter what I try, I cannot get the Era 100 to allow AirPlay. I can stream directly to it with the Sonos app, but not AirPlay. However, AirPlay works fine with the ARC based theater group. The Era device can be seen by AirPlay, so the announcements work. It just won’t connect.

I even went as far as putting the home and AirPlay VLANs in the same firewall zone and allowing ANY<-->ANY on all ports. Still nothing from the Era.

I’ve also tried rebooting it...in case anyone from Sonos IT reads this :)

Now I don’t understand the details of mDNS, VLANs or Airplay, but this person does:

https://www.derekseaman.com/2023/10/part-3-smart-home-matter-and-thread-deep-dive.html

Flatten your network. All of your IoT devices, smart home hubs (like Apple TV)  and Home Assistant servers should be on the SAME VLAN. If you really want to isolate your IoT devices, go for it, but put your HAOS server and smart home hubs on that IoT VLAN and just open TCP ports to HA from your primary network as needed. This is vastly safer than trying to do mDNS forwarding across VLANs. mDNS is designed to be used in a single layer 2 domain, so don’t expect it to work reliability across VLANs. Just don’t!!!! 

There’s a lot in the post I linked, but it seems to be clear: mDNS between VLANs is a very bad idea.

So the advice is to let every piece of cheap IoT gear see your whole network and phone home? If all of your IoT, Hubs, and Controllers are in the same VLAN, that is pretty much everything in most households. Outside of this single issue with the Sonos Era 100, all of my other devices work great in this configuration. They can’t see anything except the home hubs.