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. 

I generally prefer a manual update, so I am in control, can review release notes etc before applying

The ‘workaround’ seems to be to force close the App and reapply the update a bit later

PS - I noticed the 15.8 update didn’t cause any of the older P1s to reconnect to WiFi, just newer devices seemed to restart.

Next update I will take an even closer look on network during the update.

That’s alright. Leave it on manual. When you get a prompt, decline, read the notes, switch it to auto, then reset it in the morning. 

A good compromise, thanks.

Just want to add what worked for me (and what didn’t) here:

Sub refusing to update with error 30. Sonos system using home 5GHz wifi.

• Power cycled sub several times, same error.
• Reset sub several times, same error.
• Connected sub directly to router with ethernet cable and reset sub. Same error several times.
• Connected sub back on wifi and reset. Same error.
• Power-cycled (restarted) router: sub update worked FIRST TIME!

I hadn’t tried restarting the router previously, because every other device on our home wifi was working flawlessly and I didn’t think it sounded at all likely that the router was at fault. I had an Error30 with one (out of 4) of my Sonos Ones, and after many update attempts (and resets) the update worked perfectly immediately after I updated my Sonos app on iPhone, so I concluded that the error had been addressed in an app update somehow. But, having run out of ideas, I finally tried restarting the router, and the sub update worked immediately. I’m not sure why. Perhaps when the router’s DHCP wifi allocates new IP addresses to the Sonos devices, something in the update works differently. I don’t know. But just wanted to let others who might be stubborn like me and be think “There’s nothing wrong with my home wifi, I’m not restarting the router!” to just try it anyway.

Good luck :)

You can prevent this mayhem (duplicate IP addresses) by “reserving” IP addresses in the router. I reserve IP addresses for all regular network clients in addition to SONOS. There’s no point reserving an address for an occasional visitor’s phone.

SONOS system updates reboot all of the players and they’ll all ask for an IP address. The sudden barrage of DHCP requests can fluster the router. You can accidentally experience flawless updates 100 times in a row, then the Phantom strikes during 101 and SONOS is blamed as being broken. Community regulars all reserve IP addresses and we haven’t crossed swords with the Phantom in years.

I spent many boring hours trying to find the DHCP issue way back when because I thought it better to fix the real problem than put the “static/reserved IP” band-aid on it. After many hours of work and much power-cycling of my Sonos I realized I wasn’t going to find anything.

Set the IPs years ago and all has worked since then. It is the first thing I do when I get a new Sonos as it also solves issues here with the initial setup as well as power-cycles and updates.