Static IP address

You're behind the times. Other than for fixed devices which have no option (such as the gateway/DHCP server itself) the approved method is to use DHCP. Where an IP needs to be predetermined, utilise reservation in the DHCP server to preserve the MAC-IP mapping.

Use of static IPs (including that of gateway and DNS) configured directly into each device is error-prone and deprecated.

Oh, and MAC filtering is no security blanket at all. Sniffing a valid MAC address off the WiFi is trivial. Use a secure WPA2 key.

This is the laziest, most asinine implementation of the TCP/IP stack that you could possibly produce. If you don't want to put the work into implementing TCP/IP so that you can manually enter IP information, then you shouldn't use the protocol. You idiot consumer electronics companies just don't get it.

I just registered to like this comment. Thank you.

I've worked with hard core network types and raw consumers. I understand the network type's methods and their comfort with complete specificity and control, but this scheme does not work well with the regular consumers who are not capable of or not interested in configuring all of the details of their network. I've seen too many consumers who, when experiencing a problem, start digging for obscure options -- one of these will fix my problems, right? This 192..x.x.1 (whatever that means) works great for my router, it must work for my SONOS system too, right? Um ... that didn't work ... maybe I should use the 192.x.x.10 that my computer uses. Um, ... maybe I should pick a random number, but wait ... my router is also using 73.x.x.55 ... maybe I should use that number. Oh!, ... "root," .., there's a real option ... I'll set that for max ... Um ... or should I set it for min?

The above creates a support mess and likely robs the consumer of the plug and play experience that they wanted. If a consumer product is associated with "complicated," it will not achieve mass acceptance. For millions of SONOS players, DHCP based plug and play has worked well over the years.

There are numerous music playing products that require professional installation and work exclusively with fixed IP addresses. There is no need to fuss with SONOS products if you prefer the "professional" setup experience.

I can't imagine the confusion that would result if one was required to manually reconfigure cellphones, pads, and computers when moving from tower to tower or between hot spots.

This is the laziest, most asinine implementation of the TCP/IP stack that you could possibly produce. If you don't want to put the work into implementing TCP/IP so that you can manually enter IP information, then you shouldn't use the protocol. You idiot consumer electronics companies just don't get it.
I just registered to like this comment. Thank you.
Pity it's based on multiple misconceptions. Sonos didn't implement a TCP/IP stack; under the bonnet it is simply Linux. Moreover, people ranting like this just don't get the Sonos network architecture; they're not conventional single-homed hosts like (say) your TV or Playstation is. There are multiple physical and virtual bridge interfaces involved. Some of them don't even have IP bindings.

The only advice worth following is: use DHCP for IPv4 address assignment to all interfaces on devices that aren't internetwork gateways or DHCP servers.

Anything else is unprofessional.

This is the laziest, most asinine implementation of the TCP/IP stack that you could possibly produce. If you don't want to put the work into implementing TCP/IP so that you can manually enter IP information, then you shouldn't use the protocol. You idiot consumer electronics companies just don't get it.
I just registered to like this comment. Thank you.
Pity it's based on multiple misconceptions. Sonos didn't implement a TCP/IP stack; under the bonnet it is simply Linux. Moreover, people ranting like this just don't get the Sonos network architecture; they're not conventional single-homed hosts like (say) your TV or Playstation is. There are multiple physical and virtual bridge interfaces involved. Some of them don't even have IP bindings.

The only advice worth following is: use DHCP for IPv4 address assignment to all interfaces on devices that aren't internetwork gateways or DHCP servers.

Anything else is unprofessional.

The problem is their architecture doesn't work well on a network that isn't flat. In my case, trying to configure/setup/update/use the SONOS Connect player, regardless of the fact that its primary ethernet interface and its WLAN interface both picked up IP addresses in their respective VLANs, the device's multicast comms couldn't jump from subnet to subnet.

This is a pretty crippling setback of the unit, and isn't an issue for most modern devices within SONOS's competitive landscape.

The architecture is based on the UPnP standard, for which device discovery with SSDP relies on local subnet broadcast. (That said, some have managed to implement SSDP forwarding between subnets.)

Crippling setback? The sales don't exactly suggest that. Sonos is designed for a home/SOHO environment. Indeed it calls itself the "wireless home sound system". The vast majority of such networks are flat, or if they're not it's usually because of an accidental double NAT.

Crippling setback?
Erm...plug in...tap controller...press button...erm....erm....erm...

What's crippling.

Crippling setback?
Erm...plug in...tap controller...press button...erm....erm....erm...

What's crippling.

Agreed. I'm already hitting a wall of ultra fanboyism - understand that critical evaluation can sometimes actually be a good thing, and that your wall of "can't" or "par" is only temporary. The product plug in, controller tap, button press didn't work on our network, and I spent a few hours on the line with support to try and get things working. They had noted that one of their Tier 2 engineers would be able to help me hack something together, but that the configuration wouldn't be supported going forward.

The Sonos product will evolve over time if it wants to be successful. If their current customer networks are SOHO networks, so be it. The unit still needs some work on the interface side. That being said, I'm completely comfortable behind a terminal, and don't mind jumping through hoops to make shit work. It's what I do every day.

My point is that, in an enterprise environment where multiple subnets are in place, and subnet broadcasts/packet forwarding is easily implemented, I was told in a phone call with support said that they wouldn't support their own device on our network because of how our network was designed. Mind you, we're not a huge enterprise, and have a fairly simple network as-is. Their unwillingness to work with customers in the same situation as us immediately carves out a part of the market that their product isn't available to, and currently they're OK with this. I'd imagine that complacency won't last forever.

Again, sure, maybe the device wasn't "designed" to do the simple task that many other devices on our network are capable of. A better, easier to use, competitively placed product will inevitably come along and require that Sonos evolve their product to meet market requirements in order to remain successful. The fact that I had to type in direct HTML URI's in order to troubleshoot the unit brought me back to the days of NT - even then, many home network appliances had better interfaces than what the Sonos product has to offer today. The product already has a built-in web server. Why not make it look nice, and make it easy to access all of the troubleshooting tools from one interface, or easily found on one interface?

I'm not bashing the product to just put it down. I'm hoping that Sonos matures its offerings with critical feedback received from its customers. The backlash from this community will make it pretty hard to elicit good feedback from customers that are ready and willing to pay for your product, while also offering feedback to help the product grow. 😳

Once again, a person with a unique configuration that doesn't apply to 99.99% of Sonos installations comes on here to complain, proceeds to hyperbolically equate not catering to their unique situation as a fatal flaw (oh sorry, make that a "crippling setback") and somehow those who explain the uniqueness of the situation are nothing but "ultra fanboys"?

And you expect us to take you seriously? You might have done better if you canned the insults and started with paragraph 2. We would have taken you more seriously. Because as of paragraph 1, most have written you off as just another case of "It's easier to fire the customer!" and your ideas, as perfect or flawed as they may be, are already brushed off as tl;dr. :8

The problem is their architecture doesn't work well on a network that isn't flat. In my case, trying to configure/setup/update/use the SONOS Connect player, regardless of the fact that its primary ethernet interface and its WLAN interface both picked up IP addresses in their respective VLANs, the device's multicast comms couldn't jump from subnet to subnet.


You are wrong. Their multicast traverse at least one router jump, if your router allows it. I have personally gotten Sonos to work in a multi-layered, VLAN separated environment. It's not easy, but if you have that setup, you should be able to figure it out. Sonos cannot traverse VLANs (subnets) unless your equipment allows it. Most don't, by default.

And why would the WLAN interface and the ethernet be active at the same time, on different VLANs? In SonosNet mode, the WLAN interface is only a Sonos exclusive mesh network. In WiFi mode, the ethernet connection should not be used, or be used on the same VLAN as the WiFi, otherwise you get the issue you are referring to (which isn't surprising, at all). Just connect it properly instead.