Skip to main content

Subnet Masking Effects on Arc Surrounds

  • February 11, 2026
  • 12 replies
  • 104 views

A couple weeks ago after a firmware update, my Arc stopped communicating with the ERA100 surrounds. After a few days of hoping the problem would correct itself, no such luck. The error was “not connected’ for the surrounds. After trying several simple fixes (reboot, etc.) I ended up resetting the surrounds to factory. The Arc was working normally so I didn’t do anything to it.

After a number of failures with the same result, I called tech (non)support.  Their analysis of the diagnostics was that the surrounds weren’t getting an ip address. We have a commercial grade infrastructure with a central dhcp server and multiple Aruba access points. The subnet is 255.255.0.0. The Arc is 10.11.190.x and the surrounds are 10.11.187.x, which are in the same subnet.

The next step they want is a “complete network layout or network map. Including the make and the model of router.” For security, I hesitate to give such total information to anybody. So next, I took the surround additions step by step. After deleting them from the app and doing a factory reset, I added each one to the system, including them in the same room as the Arc. I checked with IT and got the ip addresses of the surrounds and can ping them and the Arc from my computer, so the surrounds are definitely on the network and same subnet as the Arc. When I gave the data to support, the tech said that they were on different subnets and that the third octet had to be the same for both Arc and surrounds. Not true - because of the subnet mask, they are on the same subnet.

Now, the next step. Adding them as surrounds to the Arc. The process (as far as the app can show, goes normally and finishes with a “success”. But alas, no sound from the surrounds. AND, I can no longer ping them; they have lost their ip addresses.

Any clues as to what is happening? Saying the third octets must be the same only applies if the subnet mask if 255.255.255.0. Is it possible that Sonos’ programming has forced the Arc to look only at ip addresses that have identical first three octets? And if it fails, why are the surrounds losing their ip addresses, which are valid for the overall network and are on the same subnet as the arc?

Any ideas will be helpful. I don’t know if ip reservation is possible. Our IT department may not allow it. Will factory resetting the ARC (which I really don’t want to do) force all of them to pick up new ip addresses, which would maybe make the system happy. Whatever works, it would certainly make me happy.

12 replies

Airgetlam
  • February 11, 2026

Remember, the surround speakers (of any type) are getting their IP address from the router, but through the Arc (via a proxy process). If the ‘radio/wifi’ has been turned off on either the Arc or the surrounds, and you haven’t wired both with Ethernet cables, they won’t communicate. Similarly, if your router has been updated in some way either an option not to allowed proxy connections (possibly manually, possibly through a not so helpful update) the system won’t work.

Since all of this has to do with the router, and not Sonos, doing any factory resets won’t make a difference, as you’ve found, and in fact, at best they delete file that could tell Sonos what happened…they certainly erase all error logs from the Sonos. Unless directed by a Sonos employee, I’d stay away from this option in the future. 

Also, the surrounds communicate (and receive IPaddresses) from the router normally, when not set up as surrounds, so they’d likely be pingable anyway. It is the process of setting them up as surrounds that cause them to grab on to the Arc’s signal, and then get appropriate IP addresses from the router through the Arc.

I am always concerned when an IT department gets involved. While they usually know tons about ‘normally devices, theta rarely know anything about Sonos, both in terms of connections, and crosstalk. The way they communicate is within normal network standards, but wildly different than most every other device your system may be using. 

I would really recommend another call Sonos Support to discuss it. Hopefully, you’ll get a rep who has a bit more knowledge, and can more effectively read a diagnostic.

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.


  • Author
  • Contributor I
  • February 12, 2026

Thanks for your reply. All is wireless. I factory reset the surrounds at tech supports request, and they have diagnostics, both from the original problem and latest after the surrounds were added to the system but not configured as surrounds. When we were discussing subnets, the tech had no concept about subnet masking. I asked for it to be escalated to a higher level and she refused unless I submitted complete information about our network. I asked her to be specific about what she needed and the answer was almost the same.

Your comment about “they have tools at their disposal” is laughable. I talked with them in depth twice and didn’t get any useful answers, and a request to escalate was stalled.

I see a major flaw here. It is highly irresponsible for a company that requires its system to work through common networks to have hidden, built-in requirements that make it virtually impossible to allow the system to work. It’s no wonder normal users have so many problems with Sonos equipment. Introducing non-standard requirements results in an inoperable system.


106rallye
Forum|alt.badge.img+18
  • February 12, 2026

Wait, you are using a consumer product on a network that needs an IT department and complain about Sonos making things difficult?


Forum|alt.badge.img+17
  • Local Superstar
  • February 12, 2026

We have a commercial grade infrastructure with a central dhcp server and multiple Aruba access points.

 

I checked with IT and got the ip addresses of the surrounds and can ping them and the Arc from my computer, so the surrounds are definitely on the network and same subnet as the Arc.

Your ‘commercial’ grade network configuration is probably detecting the surrounds as an ARP Spoof and blocking communication when they are bonded to the Arc, ie when the IP is bridged via the Arc MAC address.

I would check with your IT, they should be able to reconfigure this:

https://arubanetworking.hpe.com/techdocs/AOS-S/16.11/ASG/YC/content/common%20files/mon-dyn-arp-pro.htm

As mentioned above, if you install Sonos on enterprise network, it needs to be configured by a network engineer first. Plenty of helpful guides, eg:

 


Manaf3ue
Forum|alt.badge.img
  • Lyricist II
  • February 12, 2026

Your network is likely blocking the Arc from assigning IPs to the ERA100 surrounds. Adjust Aruba’s ARP/port security to allow Sonos traffic. Factory resetting the Arc won’t help since the issue is network-related.


  • Author
  • Contributor I
  • February 12, 2026

It looks like none of those is the cause. The network engineer checked all of that and none of the network stumbling blocks is there. It turns out that the Arc is using 5G and the ERA’s are using 2.4G. The suggestion to turn off 5G is ludicrous. In today’s world, I can’t imagine why you would produce a speaker that is only 2.4G, particularly when the soundbar it will most likely connect to uses 5G. At least you could have an option to turn off 5G on the Arc and force it to use 2.4G.


Stanley_4
  • Grand Maestro
  • February 12, 2026

If your network was working as Sonos expects (like a normal home network) there would be no issues with the 2.4 and 5 gHz split, mine are quite happy that way here.

We do see reports here of home networking equipment that isn't working as expected and needs workarounds to bypass the issues when using both bands.


Forum|alt.badge.img+6
  • Prodigy I
  • February 12, 2026

Sonos surround sound systems create a dedicated, private 5GHz network to connect the soundbar (e.g., Beam, Arc) to surrounds and the Sub, often using high-band 5GHz channels (such as 149-165) for low-latency communication. While the main system can connect via 2.4GHz (channels 1, 6, or 11), the surround audio bond is 5GHz. 

  • Surround Bond: The main home theater speaker (Beam/Arc/Ray) broadcasts a 5GHz network, to which the surround speakers and Sub connect directly.
  • 5GHz Channels: These connections typically operate on 5GHz channels like 149, 153, 157, 161, or 165.
  • 2.4GHz Use: The primary speaker connects to the home router via 2.4GHz (using channels 1, 6, or 11) or Ethernet, while the surround speakers use the 5GHz link.

  • Author
  • Contributor I
  • February 13, 2026

 

  • 2.4GHz Use: The primary speaker connects to the home router via 2.4GHz (using channels 1, 6, or 11) or Ethernet, while the surround speakers use the 5GHz link.

Sorry to disappoint, but my Arc is connecting to the network on 5G and the surrounds connect to the network on 2.4G. What we can’t see is the communication between the Arc and the surrounds.


Stanley_4
  • Grand Maestro
  • February 13, 2026

My Arc Ultra is connecting to my AP on 2.4, as are the associated Era-100 Surrounds and Sub 4. Other speakers are a mix. Interestingly one of my 300 stereo Pairs is split one on 2.4 and one on 5. The other is also split and the attached Sub v2 is on 2.4.

Regardless of what they use to connect to the Wi-Fi the home-theater sets use  the private and not-exactly wifi 5 gHz link for low latency audio. With professional gear you should be able to see the Sonos 5 gHz signal, it just won't show up as Wi-Fi on your scanner.


Forum|alt.badge.img+6
  • Prodigy I
  • February 13, 2026

 

  • 2.4GHz Use: The primary speaker connects to the home router via 2.4GHz (using channels 1, 6, or 11) or Ethernet, while the surround speakers use the 5GHz link.

Sorry to disappoint, but my Arc is connecting to the network on 5G and the surrounds connect to the network on 2.4G. What we can’t see is the communication between the Arc and the surrounds.

The previous post content was taken from Sonos…

As an observation though my 300's (and Sub4) do not show as connected on my (home) network at all when set up as surrounds and my ultra connects via 2.4 which, to my reading, is in line with previous information.

However I do no run subnets so 🤷🏼‍♂️


Forum|alt.badge.img+17
  • Local Superstar
  • February 13, 2026

It looks like none of those is the cause. The network engineer checked all of that and none of the network stumbling blocks is there. It turns out that the Arc is using 5G and the ERA’s are using 2.4G. The suggestion to turn off 5G is ludicrous. In today’s world, I can’t imagine why you would produce a speaker that is only 2.4G, particularly when the soundbar it will most likely connect to uses 5G. At least you could have an option to turn off 5G on the Arc and force it to use 2.4G.

Assuming its Arc Ultra, it can use 5GHz radio. No need to turn off 5GHz. You just need to your network engineer to configure the network your are connecting to. There is lots of useful info in the link I posted above. What I think is happening is your network is blocking communication when it sees the MAC address change when the surrounds are bonded to the soundbar, and/or there is arp-proxy cache issue on your the APs. If the network engineer needs assistance, they should open a case with Aruba.