Sonos update on Sub failed error 30 in wireless WM: 1 configuration

If I take a closer look at my system, in particular the Arc & Sub, in the about my system it gives MAC address and IP address, I assume this is correct:

Sonos Arc: Lounge
Serial Number: 48-A6-B8-xxxx
Sonos OS: S2
Version: 15.7 (build 74043312)
Hardware Version: 1.27.1.8-2.2
Series ID: A100
IP Address: x.x.x.212
Audio In: 
WM: 1
---------------------------------
Sub: Lounge
Serial Number: 94-9F-3E-xxxx
Sonos OS: S2
Version: 15.7 (build 74043312)
Hardware Version: 1.8.6.6-2.2
Series ID: A101
IP Address: x.x.x.213
WM: 2

2 different MAC address and different IP. However what is interesting if I ping these IPs from my PC on same network the ARP table is showing the *same* MAC address for both IP in my PC ARP table, ie the ARC:

 x.x.x.212         48-a6-b8-xxxx     dynamic

  x.x.x.213         48-a6-b8-xxxx     dynamic

So it seems in normal operation the Arc is proxying the Sub IP (213) address via the dedicated HT 5GHz network.

I look on the router ARP table and I see:

x.x.x.212     48-A6-B8-xxxx     SonosZP     
x.x.x.213     94-9F-3E-xxxx     SonosZP  

When the update is initiated the MAC address changes as its using the 2.4GHz on Sub, and this could possibly be causing network issue for the update?

I would appreciate if any network gurus running wireless WM:1 mode with Arc & Sub sees similar.

It sounds like a glitch. Error 30 is an inability to get the f/w image. Powercycling the Sub may have kicked it out of its stupor. 

The HT satellites use 2.4GHz when not handling audio. They still connect back through the HT master.

As for STP, it’s not relevant in station mode (“wireless setup”) so sometimes HT satellites can get a bit carried away when they can’t see a superior root anywhere, and each then figures it’s root. Ignore it. 

This is normal. ARP will return the HT master’s MAC. In station mode the HT master appears to be behaving the same as a WiFi extender in terms of ARP behaviour.

Just noticed this. It’s not what I’d expect to see, assuming the Sub is connecting through the Arc. It looks like it made a direct connection elsewhere. Could it have been just a transient state, as the Sub was powering up and reconnecting to the Arc?

FWIW I know that my HT satellites can never connect directly to 2.4GHz, because of whitelisting, and they always update fine. 

Thanks as always @ratty for the clarification.

Just to make it crystal for me, when I ping on the LAN from my desktop or controller on LAN its using the Arc MAC address for the Sub IP address.

When the Sub requests a f/w update via the router it uses the 2.4GHz MAC address for the same IP.

ie I will see a different MAC on router vs controller and this is normal operation, and you don’t think this would have affected the update?

I will assume it was a glitch somewhere else, and not the network.

I’m pretty sure it’s not your network, and apart from the Error 30 what you’ve reported sounds normal.

I have a Windows script which pings all the Sonos units’ IPs and also compares their MACs with the ARP table. In station mode it’s always flagged that the ARPed MAC for satellites is the MAC of the HT master. In SonosNet mode it never did this. 

In the Fing app on my phone, and WirelessNetworkWatcher too, I have the same. All the sats sort of merge with the master behind a single line entry. 

Since I see the same kind of thing with client devices attached to WiFi extenders I can only assume that there’s a similar bridging activity going on with the HT sats.

I looked the the timings for connection from my APs, and it appears the Sub did not connect to 2.4GHz during the failed update process. The timings suggest the connection was more likely when I ‘disconnected’ from the Arc as advised by Sonos support, which makes more sense. 

Everyday is a school day.

Ah, yes. Without the HT master the Sub would have found any connection it could. 

Déjà vu, same issue today with 15.8, error 30, closed App, reopened App did another update, and completed OK.

I was looking a little closer on network during update, this is my current theory:

It seems all devices download update in parallel.

The Sub is connected via Arc, so Sub & Arc IP are both using same MAC address, ie Sub is connecting to the IP network via the Arc.

Both the Sub and Arc are updating at same time, the update may involve a restart of device.

The Arc is restarting when the Sub is still communicating, maybe Sub trying to send a status message back to the App, this fails as the Arc is offline during the Arc restart.

Sub is ‘root’ STP bridge, so no network until Arc is back online.

They do, then wait for the controller to tell them to actually replace their firmware image.

They each have their own IP and MAC. The Arc is performing a bridging/proxying function for the Sub.

The units wouldn’t reboot until told to by the controller -- which waits until it has a signal from all units that they’re ready to restart. It’s possible that an “I’ve rebooted” notification back to the controller is being lost. (* see below)

Ignore STP, it’s a red herring. In station (WiFi) mode it has no relevance.

* How many devices do you have in your Sonos household? The recommendation these days, particularly for larger households, is to let everything update automatically. It takes the controller out of the equation and, I dare say, any needed retries are executed automatically. I understand that this recommendation is stronger in the case of station mode households.