Hi,
I have been running a Sonos 5 for a few years now and it works mostly good. But sometimes, the app does not find the Play5 speaker and it mostly happens at parties when it's most "critical" that it works.
I have been searching for a detailed description on the networking that Sonos is using, but haven't been able to find it.
I'm a network and security engineer and have been working with networks for 25 years. At work, I do enterprise networking, security and routing/firewalling/load balancing.
I would like to understand what network topology Sonos is using for the system to be able to debug the system when it doesn't work for me.
Is it available ?
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.
Presumably the PLAY:5 is wireless.
You didn't say how the system is set up: WiFi mode ('Standard Setup') or SonosNet mode ('BOOST Setup'). Either way, Sonos will be using a 2.4GHz signal. As you're doubtless aware this radio frequency is impeded by water and, humans being mostly bags thereof, a crowded room has a habit of causing problems.
The internal system diagnostics would reveal the wireless conditions. Have you tried submitting one and consulting Sonos Support?
You didn't say how the system is set up: WiFi mode ('Standard Setup') or SonosNet mode ('BOOST Setup'). Either way, Sonos will be using a 2.4GHz signal. As you're doubtless aware this radio frequency is impeded by water and, humans being mostly bags thereof, a crowded room has a habit of causing problems.
The internal system diagnostics would reveal the wireless conditions. Have you tried submitting one and consulting Sonos Support?
I've tried it both wireless and wired. Same situation. I do have a boost too, but it makes no difference to the "stability" of the networking. That's why I need to know the requirements of the networking protocol Sonos is using.
My wireless is Meru networks based. I have four AP832e's in my house. This is an entrerprise class wifi setup and it covers my wooden house more than well. I guess I really wouldn't need the SonosNet setup?
My wireless is Meru networks based. I have four AP832e's in my house. This is an entrerprise class wifi setup and it covers my wooden house more than well. I guess I really wouldn't need the SonosNet setup?
SonosNet is based on 2.4GHz WiFi hardware, with the same physical limitations, though the protocols are slightly different and it is of course a mesh. It also needs to use STP for loop prevention.
If you were able to run a wire to the PLAY:5 all of this would not be relevant though.
If you were able to run a wire to the PLAY:5 all of this would not be relevant though.
I have now started from the beginning with my setup and configured the Play5 wireless using a 2.4GHz SSID. I can "find" the Play5 speaker only if I'm connecting my PC to the same 2.4GHz wifi. But if I try to use it from an machine in the same L3 IP network, the app does not find the Play5 speaker. This makes me think that the Sonos system only uses L2 networking?
So, if I would like to use it over wired and wifi networks, I would have to plug it into a switch?
So, if I would like to use it over wired and wifi networks, I would have to plug it into a switch?
Sonos uses IP as normal -- as you'd see from About My Sonos System in any controller -- but all units must be part of the same subnet broadcast domain, per UPnP standards. It's not uncommon to find networks with multiple APs and wireless bands to have issues with blocked multicasts/broadcasts, particularly when the Sonos is in 'Standard Setup'. The usual culprit is a router which won't forward such traffic between 5GHz and 2.4GHz segments. Your WiFi setup may have a configuration setting in its management console to permit broadcasts.
Thanks, I haven't been able to find any reference to Sonos using L2 broadcast for finding the speakers. So, is it using multicast or broadcast to find the Play5 ?
It uses SSDP. Sniffing indicates that it actually tries both multicast 239.255.255.250 and broadcast 255.255.255.255.
Presumably there's no detailed technical info available because for most users Sonos 'just works'. If they encounter network issues Sonos prefer customers to contact Support. There are however FAQs on configuring firewalls.
If you fancy looking at things in more detail, a lot of the diagnostic information can be located at http://IP_address:1400/support/review. Use the IP of a player rather than a BOOST or BRIDGE. None of this is documented either as it's for Sonos' internal consumption, but we've figured out a few things.
If you fancy looking at things in more detail, a lot of the diagnostic information can be located at http://IP_address:1400/support/review. Use the IP of a player rather than a BOOST or BRIDGE. None of this is documented either as it's for Sonos' internal consumption, but we've figured out a few things.
To add some more technical info for you (since you are obviously well versed in networking):
It uses SSDP (as stated by ratty) for discovery. This is UDP based, and is a two way communication. The controller will send multicast/broadcast, and the players will respond to the source UDP port on the controller. SSDP is a weird HTTP over UDP sort of thing.
It uses TCP HTTP for sending control actions to the players (initiated from the controller, on port 1400 on the players).
It uses TCP HTTP _from_ the players, to the controllers, to send events. Events occurs when another controller interfaces with the players, or when stuff happens internally in the players. In order to update the state of all controllers, it uses events. The communicate with various ports depending on which controller you use (port 3400 for Windows desktop, 3500 for an Android client), but it can actually be any port since the controller will announce to the player which endpoint it should send events to.
Because of this, firewalling or segmenting the network between players and controllers is kind of a hassle. As soon as you have equipment between the controller and the players that can introduce any sort of filtering, it should be verified that the equipment doesn't in fact touch the traffic (transparent bridging, basically) to avoid problems.
It is, with some work, possible to run players and controllers on different subnets and separated with a firewall, but it is very hard to get it right, and completely unsupported.
If the app randomly fails to find the player, it is definitely the SSDP part that misbehaves. If it is intermittent, I would probably first make sure that it isn't a specific AP that gives you trouble. I guess the Meru could be trying to balance and distribute the wireless clients among your APs (if overlapping in coverage), which could explain why it happens more often when there is more people (forcing you to an adjacent AP that you rarely use to control your Sonos otherwise).
Of course, the "bag of water" argument is also very valid, but you claim that you experienced the same issue even with the Play:5 wired, meaning that it would be the wireless link between your phone and the AP that then would have to be interfered enough to disturb the SSDP. How are your APs located? High up (as recommended) or are they mounted low for esthetic reasons?
It uses SSDP (as stated by ratty) for discovery. This is UDP based, and is a two way communication. The controller will send multicast/broadcast, and the players will respond to the source UDP port on the controller. SSDP is a weird HTTP over UDP sort of thing.
It uses TCP HTTP for sending control actions to the players (initiated from the controller, on port 1400 on the players).
It uses TCP HTTP _from_ the players, to the controllers, to send events. Events occurs when another controller interfaces with the players, or when stuff happens internally in the players. In order to update the state of all controllers, it uses events. The communicate with various ports depending on which controller you use (port 3400 for Windows desktop, 3500 for an Android client), but it can actually be any port since the controller will announce to the player which endpoint it should send events to.
Because of this, firewalling or segmenting the network between players and controllers is kind of a hassle. As soon as you have equipment between the controller and the players that can introduce any sort of filtering, it should be verified that the equipment doesn't in fact touch the traffic (transparent bridging, basically) to avoid problems.
It is, with some work, possible to run players and controllers on different subnets and separated with a firewall, but it is very hard to get it right, and completely unsupported.
If the app randomly fails to find the player, it is definitely the SSDP part that misbehaves. If it is intermittent, I would probably first make sure that it isn't a specific AP that gives you trouble. I guess the Meru could be trying to balance and distribute the wireless clients among your APs (if overlapping in coverage), which could explain why it happens more often when there is more people (forcing you to an adjacent AP that you rarely use to control your Sonos otherwise).
Of course, the "bag of water" argument is also very valid, but you claim that you experienced the same issue even with the Play:5 wired, meaning that it would be the wireless link between your phone and the AP that then would have to be interfered enough to disturb the SSDP. How are your APs located? High up (as recommended) or are they mounted low for esthetic reasons?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.