Skip to main content

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

  • 7 September 2023
  • 16 replies
  • 508 views

I was stumped today, iOS updated to 15.7.1, and trying a system update to 15.7 from 15.6.

I got an update error, more details showed an error 30 on the Sub, tried again, failed.

Restarted Arc and Sub, failed again, then iOS was showing status ‘updating’ with blue icon, now stuck updating. light was off on Sub, ie not flashing as does normally when updating.

Opened Sonos Desktop App, about my system, all on 15.7 apart from Sub on 15.6. I assume Network OK, as I could ping all Sonos devices with  sub 5ms response, also able to access Network Matrix on Sub and Arc. App said there was an update, tried again failed.

Time to call Sonos support, so they could investigate diagnostic 😀

They suggested cause was a network issue, as is normally the case for any Sonos issue.

I wasn’t so sure, as I could ping all Sonos devices with latency <5ms, they have reserved IP addresses.

I managed to get the update installed eventually, involved restarting Arc + Sub several times, then disconnecting and reconnecting Sub to Arc via App.

I am still non the wiser what was the cause, I am curious, as this is only the second time in many updates (since 1.1?) that I have had update issue.

My environment is wireless (was SonosNet up until a couple of months back), and this is possibly the first or second software update in this configuration. Has been working flawlessly is this configuration for music listening including groups etc.

I have learnt today that the Sub uses the 2.4Ghz radio for updates, not the HT 5Ghz radio via the Arc. Looking at the Network Matrix, I also noticed my Sub is ‘root node’ for the STP network to the Arc, is this normal? I would have assumed the root node would be the Arc as this has the wireless uplink to LAN?

I think there could also be an issue with the iOS App, incorrectly reporting the status of updates, force closing the App resolves this.

Any network gurus have any thoughts on what I should investigate?

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.

16 replies

C
Userlevel 6
Badge +12

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.

ratty

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. 

 

I have learnt today that the Sub uses the 2.4Ghz radio for updates, not the HT 5Ghz radio via the Arc. Looking at the Network Matrix, I also noticed my Sub is ‘root node’ for the STP network to the Arc, is this normal? I would have assumed the root node would be the Arc as this has the wireless uplink to LAN?

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. 

ratty

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

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.

ratty

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?

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. 

C
Userlevel 6
Badge +12

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.

 

ratty

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.

C
Userlevel 6
Badge +12

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?

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. 

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.

 

ratty

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. 

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

C
Userlevel 6
Badge +12

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.

ratty

It seems all devices download update in parallel.

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

 

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.

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

 

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.

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)

 

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

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. 

C
Userlevel 6
Badge +12

* 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.

ratty

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

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. 

 

C
Userlevel 6
Badge +12

 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.

T

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 :)

buzz

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.

Stanley_4
Userlevel 7
Badge +22

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.

Terms & ConditionsCookie settings