Contributor I

Subnet Masking Effects on Arc Surrounds

14 replies
199 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.

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.

Show previous replies

User117655

Prodigy II

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 🤷🏼‍♂️

C

craigski

Local Superstar

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.