Added a bridge to my network and it killed it

  • 27 June 2017
  • 7 replies
  • 901 views

Just tried adding a Bridge to an existing Connect and while the Bridge setup completed successfully, it killed my Connect's ability to connect to my Sonos controller. I reset the router, rebooted the individual products and started the Bridge first, then the Connect and could eventually get the Connect added to my system, but then it dropped. Meanwhile, my router bandwidth went through the roof, averaging >3 Mbs, spiking to 15. On unplugging the Bridge, my network consumption dropped to Kbs. While the Bridge was plugged into my Buffalo router (DD-WRT v24SP2-EU-US (08/19/10) std (SVN revision 14998) ), my router was unable to correctly render its own management pages.

All-in-all, the experience of adding a Bridge was terrible.

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.

7 replies

Did you wire the BRIDGE and CONNECT to two different router ports? If wiring the second Sonos device caused the network to crash there's an STP problem. IIRC DD-WRT has an option to enable STP support.
No, the Connect has always been run wireless. All I did was connect the Bridge to the router. My android controller immediately connected and it updated its firmware. During this time, my Connect was still connected to my wireless router. Could this be a problem, should the Connect have been removed from the network while the Bridge was added? I saw no instructions to that effect.

Steps I took after this setup failure was to shutdown the Bridge and wait. After 30 minutes, I was still unable to see my Connect on either my Android or PC controllers. Strange behaviour here, too, where I added my Connect to my PC controller but it wasn't visible on my Android, and vice versa. So, after 30 minutes of waiting to see my Connect, I powered down both Sonos products, powered up my Bridge, waited to see the solid white light, connected it to my Router, waited to see it get an IP address, then went through the Add Player wizard to add the Connect. This process worked better and I was able to connect the Connect to the Bridge and could see the room on both PC and Android controllers and was able to play my Spotify playlist. However, the player jumped songs in the middle of one, saying it lost connection to Spotify, then just now stopped playing the next song entirely. That was about 5 minutes ago and still no music. My Connect might do this once or twice per day, which is why I got the Bridge. Now it's unplayable.

I'll test what happens when I change the wireless channel and report back.
Okay, well the addition of a BRIDGE (or BOOST) to a system that's in WiFi/Standard setup entails quite a bit of connection juggling by the Sonos components. IMO it's a wonder that they manage to pull it off.

Anyway by the sound of things you have a system which is now working, of sorts. Yes, check the channel allocations. Of both SonosNet and the router. They should be at least 5 channel numbers apart. Also make sure the router's not using a 40MHz channel at 2.4GHz.

One thing I'd recommend also, is to go into Advanced Settings/Wireless Setup and remove ('reset') the WiFi credentials from the system. They'd not be needed for a system in SonosNet/BOOST mode and can sometimes cause confusion.
Good tips, thanks!

So, my router had been set to auto channel negotiation and has only one fixed option, which is 4, so I selected that. No idea what channel it had been using. The Sonos defaults to 6, so I changed that to 11. My router was set to Turbo mode (40 MHz) so I'm testing dynamic (20/40) before going down to 20 (don't want to adversely affect other devices). I checked my Connect's wireless settings and they are gone; I guess connecting to a Bridge removes them, which is good thinking. I was concerned about that contention but had forgotten I had set them up in my Connect.

Thanks for your help!
has only one fixed option, which is 4
Eh? You should be able to fix the router channel on any value you like. 4 is a lousy choice, since it overlaps with 1 and 6. In fact 1, 6 and 11 are the only non-overlapping options, which is why that's all that SonosNet offers.
Agreed, was surprised to see a single option. However, on going back, now I see Auto, 5-11 as choices. Curious if the router detects collisions and gives me clear channels? In fact, it's no longer set at 4 where I put it, it's back to Auto. The good news is that Sonos has not dropped out once since making those changes. I'm continuing to test at 40MHz and so far so good. All diagnostics look good. So, may have been the initial networking negotiation that was the problem.

Of note, I had not been set to STP, because I wasn't using more than one DHCP server. Assuming that the Bridge acts as its own DHCP server, I turned on STP. That may have been the trick.

Let's hope for no more drops. :)

Thanks again
I'm continuing to test at 40MHz and so far so good.
I'd advise that you stick to 20MHz bandwidth at 2.4GHz. In a crowded RF environment 40MHz is profoundly antisocial, since it could potentially cause damaging interference for anyone within range. It doesn't fit with the 1/6/11 model of non-overlapping channels.

Use of 40MHz is absolutely fine at 5GHz, just not 2.4GHz where it can pretty much monopolise the band.

Of note, I had not been set to STP, because I wasn't using more than one DHCP server. Assuming that the Bridge acts as its own DHCP server, I turned on STP. That may have been the trick.

The concepts of STP and DHCP are totally unrelated. STP is a means of avoiding loops in a multiply bridged network. It's a layer 2 (link layer) matter. DHCP is essentially a layer 3 construct, to assign IP addresses.

In a normal home environment there can only be one DHCP server per subnet without causing addressing mayhem. The BRIDGE therefore does not host a DHCP server. It's not a router, it's a bridge.

Let's hope for no more drops. :)

Not going to disagree with that.