I have a number of Sonos amps around the house, with two being connected to different switch ports. My network kept slowing down, dropping out, then coming back on again after a few moments. Basically, my whole network was virtually unusable, and this went on for months. Eventually I traced the issue to the Sonos system on my network. When I unplugged a whole floor in my house from the switch, I miraculously could still see the servers on that floor, be it with an incredibly slow response. WOW. I traced this to the Sonos systems being connected wirelessly and passing my normal network traffic between them. This created 2 separate paths to many devices on my network: 1 via the hard wired switch ports, and 2 via the wireless connection on the Sonos. Who would have thought that Sonos acts as a wireless bridge for my standard network traffic. It seems that this caused to intermittently drive my whole network traffic through a much slower Sonos wireless connection, which I measured at around 5 MBPS because of the distance between the two of them on separate floors. Once I disabled the wireless on the offending Sonos amp and let the wired network do the job, the problem disappeared and the network is working as it should have been.
Reading the Sonos documentation stating it having a separate private wireless network, it amazes me that it is not private at all. What a terrible issue Sonos created for my family for many months after I put the Sonos amp on a different switch port.
Page 1 / 1
See this thread.
If your Sonos system was wirelessly bridging a wired backbone it's most probably because RSTP path costs are in use, though it could simply be down to a flaky wired connection somewhere. To be honest I'm surprised at your comment about SonosNet that "it is not private at all". It's been common knowledge for years that the Ethernet ports on Sonos devices could be used to extend the network to other devices.
If your Sonos system was wirelessly bridging a wired backbone it's most probably because RSTP path costs are in use, though it could simply be down to a flaky wired connection somewhere. To be honest I'm surprised at your comment about SonosNet that "it is not private at all". It's been common knowledge for years that the Ethernet ports on Sonos devices could be used to extend the network to other devices.
I'm sorry, but I don't really understand your point. There are no flaky connections and RSTP path costs (whatever that means) is not something 99.9999% of people putting Sonos on their networks would care about. The reality is that if there are 2 Sonos players wired to a network at different places (i.e. not directly to each other), then this spells disaster for the network. It creates circular paths to most devices on that network and god only knows what happens to the network packets. Most likely the network is going to get flooded, slowed down, etc. I can easily see a scenario where the switch sends a packet down a port, only to receive it back on another port, thanks to Sonos. And the switch will then send this packet again down its known port and get it back again, thus flooding the network with endless loops. There is no place for Sonos to be acting as a wireless extended of non-Sonos related traffic. This is a major issue that needs to be fixed by Sonos.
I take it you didn't bother to read the link ratty posted? Because if you had, you would have found the solution to your problem.
Yes, I did bother to read it and it is pathetic that I have to read a lengthy article of why Sonos may cause a network problem, and even more pathetic that I need to take the time and the effort to rectify a problem that should not have been there in the first place. That is not acceptable. If I wanted to buy a wireless switch repeater, then I would go and source it. I bought the Sonos system as a music player. That's it. If it decides to become something it is not, then it is a Sonos problem, not my lack of understanding of what I bought. This is a simple case of the Sonos not meeting its purpose and Sonos should fix this issue for other people that no doubt are experiencing major network issues unware of the cause.
It's actually quite easy to fix. However, you seem more concerned with complaining and blaming than actually solving your easily fixed problem. So I guess I'll go help someone else.
Well, I don't need your help as i fixed it myself already. So thanks for nothing. And you, instead of listening and acknowledging the issue, are hiding behind complex technical explanations. That's just silly, and does not help the average household user, who would not even get to this forum and will be frustrated with their network performance instead.
A SonosNet wireless mesh is a multiply bridged network. Sonos can and does automatically resolve network loops. It does so using STP (Spanning Tree Protocol), an industry standard method.
Because potential loops can also extend to the wired segments when more than one Sonos unit is wired, it's necessary in such situations for the wired paths between Sonos units to handle STP traffic correctly. If STP packets (BPDUs) are blocked the wired path goes undetected and the wireless path is left open, causing a loop.
Most network equipment behaves as it should, passing STP traffic transparently without problem. Managed switches may need STP support to be explicitly enabled. Known problems are listed here.
Your network components evidently didn't deal with STP packets as they should have. They were either mis-configured or non-compliant.
Because potential loops can also extend to the wired segments when more than one Sonos unit is wired, it's necessary in such situations for the wired paths between Sonos units to handle STP traffic correctly. If STP packets (BPDUs) are blocked the wired path goes undetected and the wireless path is left open, causing a loop.
Most network equipment behaves as it should, passing STP traffic transparently without problem. Managed switches may need STP support to be explicitly enabled. Known problems are listed here.
Your network components evidently didn't deal with STP packets as they should have. They were either mis-configured or non-compliant.
Just came across this year old thread. Gary - I am having a similar issue. For what it's worth, I totally understand and agree with what you were saying above. I'm sure you're over it by now, but I feel your frustration.
I just came across this as well after installing a new router. I was configuring the new router in my office which consists of an 8 port 1G Switch with a cat6 link to my main central switch which then is connected to my house router and then the cable modem. To configure the new router in my office, I disconnected my cat6 cable to the basement switch from my office switch, then connected to the URL 192.168.1.1 which SHOULD have been the new router, instead, the OLD router came up.... since I had disconnected the ONLY link from the office to the basement, how on earth could this be happening ? Turns out I have a SONOS connect hanging off one of the ports of the office switch and it was then connected via it's SONOS net wireless to the other devices which acted as a very poor connection from the office switch through the SONOS wireless to another SONOS connect or AMP to my basement switch.. HOLY SH&T... I was replacing the router because of very odd behavior recently and sporadic performance problems !! Well no wonder I was having problems !! The SONOS device is a CPE or an end point, it's not a network device and it should never pretend to be. The fact that it can support SONOS traffic across it's proprietary wireless network is nice, but it should NEVER forward anything from it's Ethernet ports across the wireless network, this is unacceptable behavior. I immediately disabled all of the wireless connectivity from any SONOS device with an Ethernet port that is connected via Ethernet and I have not had any odd network problems since. The fact that the only way to disable this is via a relatively obscure URL is also very concerning, this should be a CONFIG parameter on the SONOS app and it should be in huge red letters describing the affect it can have on networks if enabled. At a minimum, no SONOS device should EVER forward packets EXTERNAL to the device through the wireless network. Short of re-writing the code to disable this, SONOS should at least make the default behavior disabled.
Wow. Glad you figured it out. So what is the obscure url you can access to disable the wireless routing?
Someone had posted this in this thread, my apologies for not crediting the author, but essentially the SONOS devices all apparently have a web browser of sorts built in where you can do some additional configuration not available via the config option in the SONOS app. I went to "http://192.168.1.49:1400/wifictrl" and it came back with a page entitled "WiFi Control" which gave me a choice to select "On", "Off" or "Persist Off". I selected "Persist Off" and all of my problems disappeared. I did see some of the replies from others on this thread about spanning tree and that the SONOS OS runs RSTP and therefore it "should" not be a problem unless your router/switch doesn't participate properly, but also as someone previously mentioned, who on earth would have EVER thought that a media player could masquerade as a 3 or 4 port network switch/bridge and require a cooperating network switch to ensure no network problems occurred ? This brings up a whole host of other questions like how do you ensure quality of Service for your music flows when you're also acting as a network bridge for all of the traffic being bridged on eht0 and eth1 over the same wireless link ? Does SONOS want people to use their CONNECT and AMP as a remote wireless network switch ? I can;t imagine that this was the intended use case for the developers. As long as you have ti in there, then fine, leave the functionality there but at least make it "Either/Or", if there is a wireless link AND an ethernet link to the same network, then disable the wireless NOT BY USING spanning tree since this is obviously not reliable as my network and many others have discovered, but by simply setting the port forwarding status to off on the wireless whenever LAN connectivity is active. BTW, many many years ago I troubleshot bridged networks and had to debug spanning tree issues, they can become very complex very quickly and each vendor behaved a little differently, enough so that interoperability while assumed was never guaranteed and there are simply too many options for home network switches and router/switches to feel comfortable that your device will be 100% reliable in virtually any environment.
Some of the other commands using the http interface are located here: "http://bsteiner.info/articles/hidden-sonos-interface"
Some of the other commands using the http interface are located here: "http://bsteiner.info/articles/hidden-sonos-interface"
Ok, thanks. I’ll check it out. I think I already did that, but it was a while ago and I want to verify. Regarding spanning tree protocol, you only need to worry about STP support if there actually exist multiple paths on your network. If all your sonos boxes are wired, why on earth would you want them to route any packets at all? That would just slow things down. As you and others have said, I want my network to work as designed, without having sonos try to “help” me by adding new paths in the nw.
So I just went through all my sonos boxes. One weird thing is that when you first bring up the wifictrl page, it always says the Wi-Fi is on, even if you just turned it off. If you click “off”, it will say the Wi-Fi is disabled. But if you refresh the page, it is back to “on”. So, assuming you can actually turn it off, there’s no way to go back into that page to see what the current setting is.
I think the url I added above may give you some additional detail, in it they reference "http://:1400/support/review" which supposedly allows you to check wired and wireless network connection status as well as other things. I'm away form my home LAN now so I can't test it.
Having a similar problem. Great big new build house. Multiple managed switches (10). Two Sonos Connects. I've been having intermittent traffic slow downs, internet falling off a cliff for an hour. With so many switches and devices it was quite a task to get to the root of it which seems to be the Sonos was communicating on wireless AND wired and doing the monkey business listed above. Simply unplugging the wired cable to the Sonos seems to have cleared up the issue...but I would rather use wired than wireless.
reading all the comments above suggest there are three options:
1. Hack the url to turn wireless off.
2. Do the tree spanning config (no idea how to do that)
3. use wireless only and leave the sonos wired connections unplugged.
So, my questions are:
a) Are those the three options?
b) Of the three, what do gurus recommend.
c) If the third -- how the heck do I learn how to do that? All my switches are Netgear GS108v3, GS108v2, JGS516PE, JGS524PE
Thanks in advance-who would have thunk it!
s.
reading all the comments above suggest there are three options:
1. Hack the url to turn wireless off.
2. Do the tree spanning config (no idea how to do that)
3. use wireless only and leave the sonos wired connections unplugged.
So, my questions are:
a) Are those the three options?
b) Of the three, what do gurus recommend.
c) If the third -- how the heck do I learn how to do that? All my switches are Netgear GS108v3, GS108v2, JGS516PE, JGS524PE
Thanks in advance-who would have thunk it!
s.
One troubleshooting tool that I installed with my 16-player Sonos installation at home is to put a TP-Link WiFi controlled AC outlet on each player. This lets me remotely turn on and off each player individually when trying to isolate a problem, and lets me turn all the players off and selectively turn them back on if my system gets completely confused or when I'm working with Sonos support.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.