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.
Page 1 / 2
I think your problem may be less related to the DHCP/Static question and is instead a spanning tree problem. If you have all of them connected to physical ethernet (daisy-chained from the sound of it) it likely they are also connected to the mesh network (usually automatic.) Try connecting *just* one to the physical network, or just a bridge/boost to the physical. Try it with only two turned on: one connected directly to physical, the other just turned on and (hopefully) connected to the mesh network.
Or he could turn the wireless off, so that they don't get confused...
Userlevel 6
+15
I have 6 sonos Connect:AMP. I have to work with sonos app and with a domotic KNX interface. I need static IP's in all sonos amplifiers to work with KNX. Because of this problem (sonos don't have manual ip configuration) I changed the router and now i have one that allows configuration to set a manual IP to each sonos, but it don't work.
The sonos amplifiers are all in the same place, and the connection is serial for all 6. The cable from the router arrives to the first sonos, and another cable goes from that sonos to another until all 6 sonos are connected. Only the first works with the IP that gives the new router, but for the rest of the amps is not working. I think that when a Sonos is connected directly to another the IP is set automatically before the router assigns the manual IP.
How can I solve this?
Buying another router and changing all the installation?
Or maybe buying another amps?
I have no place for a new router.
I cannot understand why is not allowed to put a manual IP as I can do with any other product. Is a very little thing that is causing a very big problem.
Please, allow manual IP or give an alternate solution.
Thanks.
I think your problem may be less related to the DHCP/Static question and is instead a spanning tree problem. If you have all of them connected to physical ethernet (daisy-chained from the sound of it) it likely they are also connected to the mesh network (usually automatic.) Try connecting *just* one to the physical network, or just a bridge/boost to the physical. Try it with only two turned on: one connected directly to physical, the other just turned on and (hopefully) connected to the mesh network.
Then you probably haven't set it up properly - if you reserve an address under DCHP, it should simply look at the MAC address and allocate whatever you've linked it to. It doesn't matter how it's physically cabled.
https://en.community.sonos.com/troubleshooting-228999/sonos-manual-ip-6789500
Then you probably haven't set it up properly - if you reserve an address under DCHP, it should simply look at the MAC address and allocate whatever you've linked it to. It doesn't matter how it's physically cabled.
Can we abandon this thread please? You should not have double posted in the first place
Hello. That's not true. I assigned manual IP for the six sonos. Only the first amp, the one that goes directly to the router have the correct IP from the router. If I use another amp as first is the same thing, only the first has the correct IP. The rest have automatic IP
I have 6 sonos Connect:AMP. I have to work with sonos app and with a domotic KNX interface. I need static IP's in all sonos amplifiers to work with KNX. Because of this problem (sonos don't have manual ip configuration) I changed the router and now i have one that allows configuration to set a manual IP to each sonos, but it don't work.
You should just be able to reserve a specific address for each of the Sonos units in your router. So you still use DHCP, but the Sonos units always have a specific IP address.
Hello.
I have 6 sonos Connect:AMP. I have to work with sonos app and with a domotic KNX interface. I need static IP's in all sonos amplifiers to work with KNX. Because of this problem (sonos don't have manual ip configuration) I changed the router and now i have one that allows configuration to set a manual IP to each sonos, but it don't work.
The sonos amplifiers are all in the same place, and the connection is serial for all 6. The cable from the router arrives to the first sonos, and another cable goes from that sonos to another until all 6 sonos are connected. Only the first works with the IP that gives the new router, but for the rest of the amps is not working. I think that when a Sonos is connected directly to another the IP is set automatically before the router assigns the manual IP.
How can I solve this?
Buying another router and changing all the installation?
Or maybe buying another amps?
I have no place for a new router.
I cannot understand why is not allowed to put a manual IP as I can do with any other product. Is a very little thing that is causing a very big problem.
Please, allow manual IP or give an alternate solution.
Thanks.
I have 6 sonos Connect:AMP. I have to work with sonos app and with a domotic KNX interface. I need static IP's in all sonos amplifiers to work with KNX. Because of this problem (sonos don't have manual ip configuration) I changed the router and now i have one that allows configuration to set a manual IP to each sonos, but it don't work.
The sonos amplifiers are all in the same place, and the connection is serial for all 6. The cable from the router arrives to the first sonos, and another cable goes from that sonos to another until all 6 sonos are connected. Only the first works with the IP that gives the new router, but for the rest of the amps is not working. I think that when a Sonos is connected directly to another the IP is set automatically before the router assigns the manual IP.
How can I solve this?
Buying another router and changing all the installation?
Or maybe buying another amps?
I have no place for a new router.
I cannot understand why is not allowed to put a manual IP as I can do with any other product. Is a very little thing that is causing a very big problem.
Please, allow manual IP or give an alternate solution.
Thanks.
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.
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
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
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. 😳
Crippling setback?
Erm...plug in...tap controller...press button...erm....erm....erm...
What's crippling.
Erm...plug in...tap controller...press button...erm....erm....erm...
What's crippling.
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? 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.
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.
Userlevel 4
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.
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.
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.
I just registered to like this comment. Thank you.
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.
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.
For me, Infrastructure type equipment that lives on a shelf and does whatever it does, should be hard wired and set to a static IP.
They aren't going anywhere and this keeps quite a bit of (limited) throughput off the wifi band.
Done.
Phones, tablets, laptops (i.e. people) come and go on the network, only represent one user worth of throughput and typically prefer to be wireless.
And because the printer, scanner, NAS, SONOS or other device is hard wired, the bit stream goes to the access point antenna and then stays on hard wire to or from its destination instead of being broadcast back out to a wireless device...
Statit IP's 192.168.1.1 through 192.168.1.50 or 192.168.1.200 even for infrastructure, and let the DHCP assign IP addresses after that.
How many darn items can you actually have anyhow...? 50? 100?... 200...!?
Set it and forget it for the stuff that sits there and DHCP for the rest.
Why not add a little extra soho network security is to give your router an exclusive list of MAC addresses??
It is wicked annoying you cant assign a SONOS device its own IP address, though.
Just seems kinda silly to not have that interface.
My SOHO network days only go back to win 95 over BNC and even there they had this in the tcp ip settings....
Almost like you;d have to go out of your wat to not have this feature.
They aren't going anywhere and this keeps quite a bit of (limited) throughput off the wifi band.
Done.
Phones, tablets, laptops (i.e. people) come and go on the network, only represent one user worth of throughput and typically prefer to be wireless.
And because the printer, scanner, NAS, SONOS or other device is hard wired, the bit stream goes to the access point antenna and then stays on hard wire to or from its destination instead of being broadcast back out to a wireless device...
Statit IP's 192.168.1.1 through 192.168.1.50 or 192.168.1.200 even for infrastructure, and let the DHCP assign IP addresses after that.
How many darn items can you actually have anyhow...? 50? 100?... 200...!?
Set it and forget it for the stuff that sits there and DHCP for the rest.
Why not add a little extra soho network security is to give your router an exclusive list of MAC addresses??
It is wicked annoying you cant assign a SONOS device its own IP address, though.
Just seems kinda silly to not have that interface.
My SOHO network days only go back to win 95 over BNC and even there they had this in the tcp ip settings....
Almost like you;d have to go out of your wat to not have this feature.
By the way DCP does not in any way equal DHCP moron
yep... and isn't it curious that wikipedia considers DHCP as optional... as in, it is a moot point... There can be no network traffic UPnP or otherwise without a link. DHCP or otherwise link is established then network traffic is started. Yes, All UPnP devices must default to DHCP for true plug and play but as long as they can establish a link they do not care how that was done. UPnP still functions under static so stop trolling. You know nothing of networks.
So what do you think about reserving IPs on the router for each Sonos product?
It's a good idea to reserve all devices that are regular network clients.
If you are using any of the original SONOS controllers, they have an IP address too.
It would still default to DHCP and to the average user, they'd never even know there was an option. Just like with home networking. Everything defaults to DHCP and it takes experts like us to dig deeper and go static. Why not have the choice? UPnP does not require DHCP, I don't know where you heard that... It's just plain wrong.
{taken from Wikipedia on UPnP protocol}
The UPnP architecture supports zero configuration networking. A UPnP compatible device from any vendor can dynamically join a network, obtain an IP address, announce its name, advertise or convey its capabilities upon request, and learn about the presence and capabilities of other devices. Dynamic Host Configuration Protocol (DHCP) andDomain Name System (DNS) servers are optional and are only used if they are available on the network. Devices can disconnect from the network automatically without leavingstate information.
{end Wiki}
Please refrain from saying you can't handle managing a static IP environment and therefore it shouldn't be an option. For those of us who can and do, life is much easier. To each his own, don't limit me because of your ineptitude. Sonos already has massive amounts of hidden tools that the consumer knows nothing about. This would be hidden along with them.
{taken from Wikipedia on UPnP protocol}
The UPnP architecture supports zero configuration networking. A UPnP compatible device from any vendor can dynamically join a network, obtain an IP address, announce its name, advertise or convey its capabilities upon request, and learn about the presence and capabilities of other devices. Dynamic Host Configuration Protocol (DHCP) andDomain Name System (DNS) servers are optional and are only used if they are available on the network. Devices can disconnect from the network automatically without leavingstate information.
{end Wiki}
Please refrain from saying you can't handle managing a static IP environment and therefore it shouldn't be an option. For those of us who can and do, life is much easier. To each his own, don't limit me because of your ineptitude. Sonos already has massive amounts of hidden tools that the consumer knows nothing about. This would be hidden along with them.
Userlevel 6
+3
@buzz,
So what do you think about reserving IPs on the router for each Sonos product?
So what do you think about reserving IPs on the router for each Sonos product?
SONOS is standards driven and they use UPnP under the covers. UPnP requires DHCP.
I have some friends who are hard core network types and would never own SONOS simply because they can't assign static IP addresses. This is a shame because SONOS would become the most trouble free client on their network.
I recently mentored a networking guy who usually operates in the corporate network environment where one uses managed switches and routers. While SONOS usually "just works" when used with consumer level network gear, the corporate guy struggled with SONOS because, ... er ... he didn't quite get his corporate level network settings correct. In this particular case, static addresses would not have been any help.
For the audience that SONOS is targeting, DHCP is the way to go because these users do not have the technical skills or interest to fully manage a network.
I have some friends who are hard core network types and would never own SONOS simply because they can't assign static IP addresses. This is a shame because SONOS would become the most trouble free client on their network.
I recently mentored a networking guy who usually operates in the corporate network environment where one uses managed switches and routers. While SONOS usually "just works" when used with consumer level network gear, the corporate guy struggled with SONOS because, ... er ... he didn't quite get his corporate level network settings correct. In this particular case, static addresses would not have been any help.
For the audience that SONOS is targeting, DHCP is the way to go because these users do not have the technical skills or interest to fully manage a network.
Page 1 / 2
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.