Arc Ultra Surrounds Disconnect Daily After Extended TV Off Period

First, stop factory resetting. This erases any error logs that Sonos might use to help you. 

In response to your questions:

The surrounds are supposed to maintain the connection to your soundbar. The fact that they’re disconnecting suggests an issue with your soundbar, your surrounds or your router…we don’t know which yet.

I would recommend that you submit a system diagnostic within 10 minutes of experiencing this problem, and call Sonos Support to discuss it. Don’t post the resulting diagnostic number here.

There may be information included in the diagnostic that will help Sonos pinpoint the issue and help you find a solution.

When you speak directly to the Support staff, they have tools at their disposal that will allow them to give you advice specific to your network and Sonos system.

​@Airgetlam 

Thanks for the response. I have contacted Sonos support multiple times and submitted diagnostics during the issue. The last recommendation was to factory reset the Arc Ultra.

At this point, I was hoping to find someone who has experienced a similar issue and found a resolution.

I did come across a similar thread where the outcome involved adding a Sonos Boost:
https://en.community.sonos.com/speakers-229128/one-sl-does-not-reconnect-when-tv-turned-back-on-6888358?tid=6888358&fid=229128

Ah, there was no mention about the reset being suggested by Sonos.

As I’ve not experienced this on either of my home theater setups, I’ll leave you be, in the hopes you can find a resolution. 

As an offhand bet, I would suspect this has to do with a setting on your router, given that they’re ASUS, some of which appear on the problematic list…but others here use them without any issues at all.

The BOOST is old, and retired technology. It still works with some equipment that recognize a SonosNet connection, but I don’t believe the Arc Ultra has the electronics to recognize the signal.

Good luck!

​@Airgetlam Thanks. I’ve seen some mentions of ASUS-related issues as well, though most seemed tied to guest networks, which I don’t have enabled.

Out of curiosity, what router are you using for your setup?

Oddly, I’m one of those ‘troubled’ types that uses a bog standard T-Mobile 5G device that has a built in router. I don’t have access to things that T-Mobile seems to think are troublesome, such as IP reservations…but the thing works, and I do have a fairly extensive network of Sonos devices, including two home theater setups. I keep wanting to switch to my own router, but haven’t figured out which one, and given it all just works right now (and given the frequent power outages where I live), I’m not overly anxious to change things. 

That really sounds like your router doing something odd, not your Sonos.

I can power my Arc down and not get the blinking white surrounds.

https://support.sonos.com/en-us/article/sonos-led-lights

​@Airgetlam  Yes, I would not mess with what’s not broken.

​@Stanley_4  The surrounds don’t start blinking white immediately, only after an extended period of time.

I came across this Reddit post regarding ASUS DHCP issues with Sonos: https://www.reddit.com/r/sonos/comments/1ow28ko/psa_asus_dhcp_issues/

I’m wondering if the blinking begins around the DHCP lease renewal window (currently 24 hours). I increased the lease time to 48 hours and will report back after testing.

Not my Arc, but on my Beam I often end up with it powered down for days while the surrounds are powered up. No issues.

If you want to look for something Sonos is doing wrong you may spend a lot of time on that as this doesn't seem to be a common issue. 

That the surrounds are not connecting directly to your router when the 5 gHz Sonosnet from the Arc is powered down really sounds like a router issue. At least give the router logs a good look and see what it is doing with the Sonos connections.

ARC will maintain a private 5GHz connection with its surrounds. If the router assumes that these channels are not in use and assigns something else to these channels there will be trouble. Changing the lease renewal times is one step in exploring this issue. On a home network I don’t expect any issues with weekly renewals. 

​@Stanley_4 The Arc Ultra and other newer Sonos speakers don’t use the 2.4GHz SonosNet. That may explain the difference in behavior. https://en.community.sonos.com/advanced-setups-229133/sonsonet-hack-for-new-devices-era-arc-ultra-6928122

It still could be router-related. I’m currently testing whether DHCP lease timing plays a role. Hoping that helps narrow it down to something more specific.
 

Rather than fiddle the router's DHCP renewal timers, I went ahead and reserved addresses for all Sonos and avoided the issue.

Do try one or the other to eliminate the possibility.

Never said they did, I did say they use the 5 gHz Sonosnet. Poorly named and very different.

​@ScottDDev 

Do you by chance have your TV and your Arc plugged into a smart power strip wherein the TV is the command unit that triggers the power strip to send/cut power to other receptacles? If so when you turn the TV off the power is cut to the Arc which in-turn is no longer communicating with surrounds and/or sub bonded to it via the Sonos proprietary 5Ghz channel.

FYI, I use Asus WiFi 7 routers with 32 Sonos units.

​@AjTrek1 I do not. The Arc remains powered on when the TV is off. I haven’t experienced any issues with my Sonos speakers until adding surrounds.

I’m not sure if this is related, but this just happened: The TV was on but idle (Apple TV screensaver), and when I started playback the Sonos Arc Ultra status light turned green and the surrounds began blinking white.

They reconnected after a few seconds, but the left surround is currently out of sync.

For reference, the TV is an LG C9 OLED TV.

OK…do you have different SSID’s set for your 2.4Ghz and 5Ghz bands and 6Ggz if available? If so you should give the same SSID to all bands. Don’t force Sonos to lock onto a particular node. Let Sonos choose the band and node to connect to.

My ASUS WiFi 7 is an AiMesh with 3 routers connected via a wired backhaul. All bands use the same SSID including the 6Ghz. If using a wireless backhaul one of the 5Ghz (or the 6Ghz) bands would be used to connect the mesh.

It would be very unusual, but not impossible, to be the Arc Ultra or the surrounds. I’d certainly be looking at the router first, and perhaps specifically at the way it handles proxy IP addresses, which is what I believe the surrounds use. 

But, as ​@buzz is wont to say, as soon as you think you know what it is, it turns out to be something different. I’m paraphrasing, mind you, but I certainly agree…especially when talking networking. It always seems straightforward, then you’re taken for a loop…which also turns out to be logical, just not considered before. It is a science, after all, but…

​@ScottDDev 

As you can see all bands share share the same SSID on my network 

At the moment I’m hosting 61 clients of which 32 are Sonos. FYI, I’m viewing my network remotely over 5G cellular 50 miles away.

I have a had a quick scan of this thread, it feels to me like previous issue(s) with Asus and false positive ARP Spoofing, as the satellites share same MAC address as Arc.

https://www.google.com/search?q=ASUS+arp+spoof+sonos

Never used Asus, but just a hunch, is the AiProtection enabled?

https://www.asus.com/uk/support/faq/1008719/

Is it possible to exclude/whitelist Sonos devices from the AiProtection, if enabled?

Edit: Another useful link regarding Asus firmware with Guest Network enabled:

When the Sonos Arc Ultra is idle for an extended period (TV off / no audio), I was seeing repeated deauth/auth/assoc log entries for the surrounds, along with the surrounds blinking white.

I enabled multicast routing, and after reconnecting the system, the surrounds stopped blinking after idle and the log activity stopped.

To isolate further, I reset my ASUS RT-AX88U router and ASUS RT-AX58U AiMesh node to factory defaults and did not re-enable any custom settings. I noticed that AiProtection is disabled by default, whereas I had it previously enabled. With everything at default (and without enabling multicast routing again), the surrounds have remained connected during idle and there are no deauth/auth/assoc log entries.

I’ll continue to monitor, but at this point it appears AiProtection may be the root cause. Enabling multicast while AiProtection was enabled also seemed to prevent the disconnect/reconnect loop after idle, although I’m not sure why.

Has anyone else seen AiProtection cause similar behavior with surrounds?

I also want to note that each Sonos speaker maintains a strong, stable connection to the network individually. The issue only occurs with the surround link, which makes me think it may be related to how the Arc Ultra manages its private 5 GHz connection to the surrounds.

Or how ASUS handles the rare proxy IP connection. 

​@ScottDDev 

As you can see Asus AiProtection is fully enabled on my network. However UPnP is not turned off which Sonos uses. Again the screen shot is a remote view via the Asus app.

FYI, the only time I’ve had problems with surrounds and Subs is when the Guest Network is enabled. Asus is aware of the issue and has supposedly fixed the problem in an update. I haven’t bothered to test again as a Guest Network is really not needed by me. I just enabled it once for kicks.

​@AjTrek1 Out of curiosity, do you have multicast routing enabled on your ASUS router?

​@ScottDDev 

Here are screen shots of my settings for multicast preceded by a brief AI synopsis. I don’t recommend setting up IPTV (Internet Protocol Television); unless you have a specific need regarding your ISP.

In the ASUS Wireless Professional settings, select the 5 GHz or 6 GHz band for high-speed, low-latency performance (streaming/gaming), and the 2.4 GHz band for maximum range or older smart home devices.

​@AjTrek1 

Thanks for sharing the screenshots. That’s interesting that AiProtection is working for you with multicast disabled.

My system has been stable since resetting to default settings (with separate SSIDs for 2.4 GHz and 5 GHz) and leaving AiProtection disabled. UPnP is also disabled by default.

There may be some differences in router model or firmware version that could explain the different behavior. I may reach out to ASUS to see if they’re aware of anything related.