Sonos Arc Wired Network - DHCP and STP Issues

  • 5 March 2022
  • 6 replies
  • 478 views

Userlevel 2

Hi Folks.

I have a Sonos Beam gen2 and a Sonos ARC. I’m using Symfonisk Lamps as surround pairs with both of these setups. I’ve switched from RSTP to STP on all my switches in order to accommodate the Sonos gear, and wifi is disabled on all devices.

The Beam2 setup is rock-solid, and I never have any problems. The Sonos ARC is a constant headache despite being similarly configured. Both are wired completely, due to living in an apartment in a city and having a terribly polluted RF environ. (I’ve tried using the products wirelessly, but they get out-of-sync constantly.)

What I’ve noticed (after troubleshooting) is that sometimes the Sonos ARC will drop off of the network due to losing it’s IP address. Sometimes it’s due to a link state change caused by STP which is another can of worms I’d like to discuss if anyone has insight into running a completely wired setup and accommodating Sonos’ old deprecated STP defaults (I’m using Mikrotik as my “core” routing/switching gear and have Netgear “access layer” switches.)

When the Arc loses it’s IP address, what I see at my DHCP servers (I have 2 dnsmasq DHCP servers with non-overlapping subnets) is that there are DHCP requests that are flagged in the logs as “DHCP packet received with no address.” Before I knew what was going on when the ARC would drop off the network, I would do this whole blind routine of rebooting devices and unplugging sonos gear, but now I know how to get the device back online pretty quickly:

I’ve realized is that if I restart the dnsmasq dhcp service enough times, eventually one of the servers will be able to assign an address to the Sonos ARC (i have tried with and without reservations - no impact - so I have gone back to reservations so at least i know what IP it *should* have when it’s online). And then it appears in the app after grabbing an IP again.

So! (I have been submitting diags to sonos, and I am going to open a ticket on this issue as well.)

All of that to ask: Is anyone else seeing similarly odd DHCP behavior? I suspect it’s due to the way the sonos products hide the physical interfaces behind a bridge so that they can transition from wired to wifi and use the same MAC. If so, any fixes?

And also: Is anyone else using the products all-wired and having good results? I don’t really understand why the almost-identical beam2 setup is so solid and my Sonos ARC has been unstable since day 1.


6 replies

The Symfonisk require WiFi. If you disable the SONOS radios, ARC and BEAM cannot establish the private 5GHz link to the surrounds.

I’m not having an DHCP issues, but my WiFi environment is also polluted and there can be occasional issues. Fortunately, I can wire almost all players if necessary.

Userlevel 2

I understand that the Sonos soundbars use 5ghz for wireless surrounds when they’re in Sonosnet Mode, but the 5GHz spectrum is also polluted where I live in a major city, so I have the wireless NICs disabled. I’m not an expert on all sonos products, but all of my symfonisk gen2 lamps are on wired connections with wireless disabled, and I see 2 Mbps wired traffic to the surround speakers when using the soundbar.

The network matrix also shows that wireless is disabled, and I don’t let the devices directly connect to my SSID, so they’d have to use SonosNet from what I understand about the sonos mesh technology.

I’d still be interested in someone who has encountered/packet-sniffed the DHCP scenario I describe in the post above. 

I think that the sonos gear should disable STP if they’re all on wired with wireless disabled, but I could be misunderstanding. I’d also be interested in someone who really understand this issue. If I’m correct in what I think I’m deducing, then I should be removing the sonos STP factor from the equation - as I think that they only participate in STP if they can pass traffic on both their wired and wireless interfaces.

 

(It can be really hard to disable wireless via the app, because every time I would try to do so, the Sonos Arc would lose it’s IP address and then I would need to help it get an IP address before timing out on the interface disable routine in the app due to losing connection bc of having no IP - yowsers! One night I sat there for 45 minutes trying to disable the wifi on the last wired sonos device, before I took the time to diagnose the problem.)

Userlevel 2

An update on my situation:

What I believe was/is taking place is the sonos device’s STP was causing the switch to disable the interface, then the sonos device would lose it’s IP and not get a new lease when the interface was set to forwarding by the switch after the appropriate timers.

This is why when I cause the dhcp server to restart, it does eventually speed up the process of bringing the Sonos Arc back online due to a fresh lease from DHCP. I suspect this is happening to many folks when their sonos devices disappear from the app, but without digging in, it’s hard to determine what’s happening.

Even after verifying that the Sonos Arc wireless interface was disabled and putting the Arc and the 2 Symfonisk surrounds on the same switch, the Sonos Arc still appeared to be causing the switch to disable the interface due to STP. I don’t understand why this is happening.

Using WinBox I set the Mikrotik interface manually as an “edge port” instead of having it set to “auto” as is recommended on the Mikrotik STP page. This appears to have stopped the interface flapping. It’s been stable for 16 hours now, but I’ve learned that this is not enough time to declare a Sonos win. Oddly, I seem to have periods of relative stability with this Arc and then it will flake and descend into a maddening experience.

It is worth sharing (for the curious or bored) that I had a hard time truly disabling the wireless interface on my Sonos Arc, so I’m not 100% sure it was disabled throughout all of what I described above. (I was toggling wifi on/off at various times, and only now have realized how flaky applying the setting can be in the app.) I am certain that it’s disabled now though.

I know that auto-magic is probably great for many consumers (although I do see some pretty frustrated posts on the forum), but I probably have more robust networking gear than most and don’t want audio devices participating in spanning tree or creating their own layer 2 bridges as they wish without much influence from me. :)

 Whether or not you see any logic in it, and notwithstanding your challenging wireless environment,  would you try leaving the wireless radios on for all the speakers in your Arc HT setup and wire just the Arc?

I understand that the Sonos soundbars use 5ghz for wireless surrounds when they’re in Sonosnet Mode, 

Just to be pedantic, they do this whether or not in SonosNet mode. 

Userlevel 2

I understand that the Sonos soundbars use 5ghz for wireless surrounds when they’re in Sonosnet Mode, 

Just to be pedantic, they do this whether or not in SonosNet mode. 

That’s fair. The s-bar could be wired and have the surround satellites linked via 5 GHz (from what I understand it links to one surround and then the one surround links to the other - but i could be wrong).

I’ve tried what you’re suggesting, and I had drop-outs and will always end-up with an echo effect on music that’s intolerable.

I would be willing to try going wireless again, but right now I’m having possibly the best day I’ve had ever had as far as stability goes. If/when things get bad, I’ll give wireless another shot. Based on past experience, I could wake up tomorrow and find that the Arc is on the fritz again...

Reply