Arc Ultra Surrounds Disconnect Daily After Extended TV Off Period

I would suggest disabling UPnP on the router (a potential security risk), this will not affect UPnP on the LAN.

Agree. Different models will have different chipsets with different firmware. I would report to Asus, if you can consistently reproduce. The AiProtection does have different features that can be individually enabled/disabled and possibly configured? Ideally you want to be able to exclude/whitelist your Sonos devices. 

I spoke too soon. The issue reappeared after about 12 hours. I’m again seeing repeated deauth/auth/assoc log messages after the Sonos Arc Ultra goes idle.

This is occurring even with default router settings and AiProtection disabled.

I’ve contacted ASUS support and they said they will follow up in a couple of days.

I’m still waiting to hear back from ASUS, but I’ve done some additional testing and think I have a better understanding of what’s happening.

To clarify, my network works fine with Sonos speakers individually. The issue only occurs with the surrounds (Ones) and their connection to the Sonos Arc Ultra (private 5 GHz link).

When the Arc Ultra goes idle, there appears to be a brief window where the surrounds show up on the network again (visible in the client list), which may be by design. They will sometimes reconnect back to the Arc Ultra without issue, but other times they fully associate with the router.

When that happens, the surrounds get stuck in a loop:

• Deauth when attempting to connect to the Arc Ultra
• Auth/Assoc when reconnecting to the network

These events repeat until the Arc Ultra is power cycled.

This also explains the inconsistent behavior. If the surrounds reconnect to the Arc Ultra quickly, everything works normally. If they fully associate with the router first, the loop begins.

My current theory is that this is a timing issue during the transition between the Arc Ultra’s private 5 GHz link and the router WiFi connection.

The odd thing is that this doesn’t seem to be happening to anyone else. I’d think if it was, there would be at least dozens of people clambering about a similar issue. But it only seems to be occurring to you. 

Most odd.

​@Airgetlam I’m not sure that’s entirely the case. There do seem to be a number of reports of surrounds disconnecting or not reconnecting, although they may not all be describing it the same way. It’s possible this is specific to my router model or firmware.

​@ScottDDev 

There are questions I have yet to get answered. If you did and I missed your reply … my apologies.

Questions:

Do you have different SSID’s for your 2.4Ghz and 5Ghz bands?

Do you have a Guest Network active?

My system has been stable for a few days now, so I wanted to share an update in case it helps others.

After restoring default settings on my ASUS RT-AX88U, I made the following changes:

2.4 GHz Band

• Disabled 802.11ax / WiFi 6 mode
• Set Channel bandwidth to 20 MHz
• Set Control Channel to 11
• Disabled Roaming assistant
• Disabled Explicit Beamforming
• Disabled Universal Beamforming

5 GHz Band

• Set Control Channel to 48 (non-DFS)
• Disabled Roaming assistant
• Disabled Universal Beamforming

After these changes, the Sonos Arc Ultra and surrounds have remained stable with no more auth/assoc/deauth loops.

The last changes I made before things stabilized were disabling beamforming and setting the 5 GHz control channel to 48, so one (or both) of those appears to have made the difference. I haven’t isolated which one yet.

ASUS is still looking into it, but so far this configuration has been stable.

ASUS got back to me:

…Your changes:

Disabling Roaming Assistant
Disabling Universal Beamforming
Fixing the 5 GHz channel to a non-DFS channel (e.g., channel 48)

are all aligned with best practices for improving stability in environments where devices rely on consistent, low-latency peer connections rather than dynamic roaming behavior.

At this time:

This does not indicate a hardware fault with your ASUS router.
It is also not unexpected behavior, given how advanced wireless optimization features can interact with proprietary device communication protocols.
The configuration you applied is appropriate for ensuring stable operation of your Sonos system.

For ongoing reliability, we recommend:

Continuing to use a fixed non-DFS 5 GHz channel (36–48 range)
Keeping Roaming Assistant disabled for environments with stationary IoT or audio systems
Avoiding features that dynamically steer or modify client associations when using mesh or multi-node setups with latency-sensitive devices…

If you avoid the DFS channels that leaves you 9 channels at 5 gHz but 165 can be iffy depending on your location.  

Channels 36, 40, 44, 48, 149, 153, 157, and 161 are all good first choices. 165 is a second but not DFS choice.

Good advice on DFS, avoiding it and the channels involved 52, 56, 60, 64, 100, 104, 108, 112, 116, 120, 124, 128, 132, 136, 140, and 144 is the safe bet. 

Some possibly bad advice, if the 9 non-DFS channels are crowded and you don't have a DFS priority user (usually radar) in your area you might be tempted. I was and picked channel 100, for no particular reason, and have been using it for a long time. I haven't had any DFS events where my Wi-Fi was shutdown or forced to change channels so I'm going to keep using it. If I'd have had any events I'd have tried other DFS channels or gone back to the safe ones.

Bottom line, go with the safe option but if you are willing to experiment with little or no support...