Skip to main content

I have a Ubiquity Unifi network with a separate VLAN for my Sonos speakers. They all work perfectly fine (set on SonosNet) + a Roam on WiFi, except for the Era 100 (which is connected to ethernet with the Sonos Combo Adapter). I am unable to connect any device via AirPlay. When I move the Era back into LAN (same VLAN as other devices) it works instantly.

Sonos needs to be on a single network


Sonos needs to be on a single network

I would like to understand why the Era 100 is behaving different than all my other Sonos devices (which are in the same setup). My Beam, Sub Mini, 4x Sonos ONE and 1x Roam work perfect. It is the Era 100 who is behaving different and temporary I put than one back in my LAN (and works fine).


Sonos needs to be on a single network

I would like to understand why the Era 100 is behaving different than all my other Sonos devices (which are in the same setup). My Beam, Sub Mini, 4x Sonos ONE and 1x Roam work perfect. It is the Era 100 who is behaving different and temporary I put than one back in my LAN (and works fine).

Sounds like the port that the Era 100 is connected to is not configured correctly. Copy the setting from another port that you have a Sonos speaker connected to.

But as @Stanley_4 stated, the simplest solution is to have Sonos on the same network as the devices you use to control them.


The configuration of the ports are exactly the same. If I put the Era 100 (with the same settings) back to the LAN VLAN, all works fine.


I’m in the same boat: when I setup my new ERA100’s a few weeks ago I was able to AirPlay from my trusted VLAN to the Sonos VLAN, now AirPlay has stopped working whilst all other Sonos features are working as normal on them.

I can still use AirPlay from the trusted VLAN to my Arc in the Sonos VLAN so I believe this to be a bug in a recent update to the ERA100’s.

Network segregation is pretty normal nowadays, so I’m hoping this will get fixed in an upcoming update.


Seeing same issue too, same setup across vlans that works fine with a Roam but not the Era 100. No configuration changes done on my end and the Era 100 worked fine with Airplay up until recent.


Adding my own experience to this thread in the hopes it will help get attention from the Sonos developers / management. The latest update to the newer Sonos products (Era, Move 2, etc) has broken AirPlay across VLANs. I noticed this week that AirPlay no longer worked with my Move 2 speaker, but it is working fine with my older Sonos One and Play:5. All these devices are on the same wireless network which is on a separate VLAN from the rest of my house.

There is a discussion on reddit of the same issue: https://www.reddit.com/r/sonos/comments/1ggjxlh/airplay_to_era_100_but_not_roam_broken_across/

Could Sonos please release a new system update that fixes the issue. Thank you!


Same here….

IoT network / SONOS network / Automation / Work etc, all in different VLANS seperated… 

Now added the ERA300 in the SONOS network, but unable to play….

 

Please have this checked out…!!!


Network segregation is pretty normal nowadays, so I’m hoping this will get fixed in an upcoming update.

No, network segregation is not at all normal for home users, except for Ubquiti owners who like to make their networks complicated.

(Uni owner here, but I do not try and put my Sonos gear on its own segmented network because I prefer to stay married).


Spent a little time digging into the issue. To recap, though, everything was working fine until the `81.1-58210` software release which was installed across my system on Oct 21st. Airplay across VLANs worked fine with all speakers; after the system update, Airplay across VLANs stopped working with the newer speaker hardware.

The issue is that the Precision Time Protocol service does not start up properly on the newer speakers. When an Airplay stream is initiated, the sending device contacts the speaker on port 7000. As the devices negotiate the Airplay protocol, the Airplay device starts sending PTPv2 packets to ports 319 and 320 on the Sonos speakers. The speaker initially responds with some ICMP “port unreachable” responses because the Precision Time Protocol service is still starting up, but eventually the speaker starts sending back PTPv2 packets so the devices can coordinate on time and account for audio delay.

The newer Sonos speakers never send PTPv2 packets in response. The Airplay device is sending these packets to coordinate on time, but the Sonos speaker always responds with the ICMP “port unreachable” packets - it never starts listening for these PTPv2 packets.

Again, this only happens across VLANs - if both devices are on the same subnet, then the issue does not happen.

For corporate environments (retailers, etc) keeping devices like Sonos speakers, lighting systems, etc separate from the point-of-sale terminals is very important from a security perspective. For home users, this security by separation is just as important especially with some work-from-home environments.

Hopefully this is an error / oversight and not an intentional change by Sonos, and hopefully Sonos can remedy the situation in a future software update.

PS - If any engineers at Sonos stumble across this thread, please feel free to contact me directly and I can provide some tcpdump packet captures that illustrate the issue. The initial Airplay handshake with the speaker is successful; the speaker just never responds to PTPv2 packets on ports 319 or 320.

Cheers!


Spent a little time digging into the issue. To recap, though, everything was working fine until the `81.1-58210` software release which was installed across my system on Oct 21st. Airplay across VLANs worked fine with all speakers; after the system update, Airplay across VLANs stopped working with the newer speaker hardware.

The issue is that the Precision Time Protocol service does not start up properly on the newer speakers. When an Airplay stream is initiated, the sending device contacts the speaker on port 7000. As the devices negotiate the Airplay protocol, the Airplay device starts sending PTPv2 packets to ports 319 and 320 on the Sonos speakers. The speaker initially responds with some ICMP “port unreachable” responses because the Precision Time Protocol service is still starting up, but eventually the speaker starts sending back PTPv2 packets so the devices can coordinate on time and account for audio delay.

The newer Sonos speakers never send PTPv2 packets in response. The Airplay device is sending these packets to coordinate on time, but the Sonos speaker always responds with the ICMP “port unreachable” packets - it never starts listening for these PTPv2 packets.

Again, this only happens across VLANs - if both devices are on the same subnet, then the issue does not happen.

For corporate environments (retailers, etc) keeping devices like Sonos speakers, lighting systems, etc separate from the point-of-sale terminals is very important from a security perspective. For home users, this security by separation is just as important especially with some work-from-home environments.

Hopefully this is an error / oversight and not an intentional change by Sonos, and hopefully Sonos can remedy the situation in a future software update.

PS - If any engineers at Sonos stumble across this thread, please feel free to contact me directly and I can provide some tcpdump packet captures that illustrate the issue. The initial Airplay handshake with the speaker is successful; the speaker just never responds to PTPv2 packets on ports 319 or 320.

Cheers!


thank you for the very well explained problem discription. 
 

@SONOS when are you planning to fix this? 
as it is stated here, its not something only for home users but also for a lot of businesses where the IoT is separated from all the other networks. Can we please have a fix as soon as possible? 


I don't get it. You segregate the devices and then grant them trusted status so they are not segregated anymore?!? What's the point? How could this improve security in any way?


I don't get it. You segregate the devices and then grant them trusted status so they are not segregated anymore?!? What's the point? How could this improve security in any way?

You clearly dont know what Network Security is :)

You dont open ANY TO ANY or ALL ports… only what is required. Why should a sonos access your SMB or File shares? Or your Homesystem or Alarm securtiy or Cameras??? Did you think about having a brach on Sonos which could impact Applications or Pin terminals for payments? It all possible!!! 


That's why you are having issues. You don't know exactly what ports are required. It's a guess game.


Not just that, but your phone is also a risk to your pin terminals. So keep.your work devices on one VLAN and Sonos and its controllers (phones, tablets,.etc) in another. But don't segregate your speakers from your controllers.


Not just that, but your phone is also a risk to your pin terminals. So keep.your work devices on one VLAN and Sonos and its controllers (phones, tablets,.etc) in another. But don't segregate your speakers from your controllers.

Yeah, the phone is a much higher security risk than the Sonos speakers. Just put them all in the same VLAN...


But that is the point. 
 

All different purposed end-nodes are specified and put into different “zones”. 
Sonos devices are only allowed on “specific” ports to talk to the phones/ipads. And vica versa back. Nothing more! :)


I don't get it. You segregate the devices and then grant them trusted status so they are not segregated anymore?!? What's the point? How could this improve security in any way?

You clearly dont know what Network Security is :)

You dont open ANY TO ANY or ALL ports… only what is required. Why should a sonos access your SMB or File shares? Or your Homesystem or Alarm securtiy or Cameras??? Did you think about having a brach on Sonos which could impact Applications or Pin terminals for payments? It all possible!!! 

A more secure solution for playing music, if you are concerned about Sonos connected to your network and/or security breach, would be an analogue amplifier with no network capabilities connected to a CD player and some speakers. If you are concerned about privacy that someone may hear what you are listening to with the analogue amplifier and speakers, you could use headphones.


Please lets not diviate from the challange/problem what we are observing. 
You can put everything on a flat network/subnet if you like. 
 

Its a security principal that we would like to have this.

Done deal. So get a long :) 

 


Please lets not diviate from the challange/problem what we are observing. 
You can put everything on a flat network/subnet if you like. 
 

Apple requires the devices to be on same network:

https://support.apple.com/en-gb/105068

  1. Make sure your iPhone or iPad and speakers or Apple TV are on the same network..

.

.

Your iPhone or iPad and your AirPlay-enabled device must be on the same Wi-Fi network before you can get automatic and suggested AirPlay connections.

.

.

You can send audio from Apple TV to one or more AirPlay-enabled devices, such as HomePod and other smart speakers and TVs, that are connected to the same network in your home.

.

.

Make sure your Mac and speakers are on the same network. Open the Apple Music app, click AirPlay in the playback controls, then select a speaker or multiple speakers.

 

I agree, you can hack your network into an unsupported vendor (Apple/Sonos) configuration for fun/educational purposes, but it is then unsupported.

Maybe if enough people request it, AirPlay3 will support VLANs?


Reply