Hello everyone!

Actually not 100% false as there is no reason why the Sonos device cannot retain the IP address allocated before the update meaning that there is no reason for a new IP address to be requested.

There is of course always a chance that a change will occur during the update but saying 100% is overstating this. 

Name one device that is issued an IP address via DHCP which retains that same address through a reboot.  By the very definition of DHCP (Hint: The ‘D’ stands for “Dynamic”), no device retains an IP indefinitely, and the IP issued is determined by the DHCP device, and not by the device itself.  It is only by reserving IP addresses in the router’s allocation table that a device is issued the same address every time. 

What you speak of is static addressing, which Sonos doesn’t even use, and is the very opposite of DHCP.

​@Hulla 

In the interest of “positive” solidarity I wanted to make sure you and others who may have the same misunderstanding of what this community is about see this….

• You mentioned that it’s the fault of Sonos that your purchase account does not sync your purchased products with this community. News Flash… that would be improper for any company to expose your purchased products to a general community like this without your permission. I’m sure you’d be outraged if that were the case. What you purchase is your personal business and not that of others; unless you choose to make it public. Some would call that an invasion of privacy or publication of Personal Identifiable Information (PII).

I have spent many, many hours with some decent network tools looking for the cause of this issue.

First: The issue happens at two (common, maybe not comprehensive) times. One is a system reboot from a power failure, the second is following a firmware update/reboot, but not a Controller-only update. 

Second: Using a router with very comprehensive DHCP logging and not assigning reserved IP addresses, nothing can be seen in the logs showing assignment issues, none refused, no duplicates. Switching to reserved addresses the logging again shows no issues. I did not use a packet analyzer, it would be nice if someone did, I decided to not subject my Sonos to a large number of power cycles needed for that.

Sadly we are prevented from seeing the internal Sonos logging and can't compare their logs to our router logs.

It is obvious something is going wrong (Sonos acknowledged this, but not that it is their fault) but only for some people.

It is more common to see reports from folks with more Sonos than ones with just a few. I think there have been reports with 3 or 4 Sonos.

Changing routers can make the issue go away, even if it is going from a high end router to a cheap one pulled from the junk box.

The problem isn't consistent, you can have several reboots with no issue and then get hit at the next several. 

The one clear thing that all evidence points to is that the issue is directly related to the system wide reboot.

The reason for the reboot doesn't matter, just that it was done.

Blaming the firmware updates is pretty much impossible as they are always followed by a reboot.

To be clear Sonos needs to fix this, maybe it isn't their fault but a router or other flaw. BUT it is causing Sonos users grief and at a minimum Sonos should find a way to work around any common failure like this.

While I was typing a couple things came up.

Some routers were assign dynamic addresses via an algorithm,  based on the client MAC address, results are close to reserved addresses unless another device requests the address prior to the device that would be given it by the algorithm. So far nobody has posted any data on how this impacts the Sonos reboot issue.

DHCP servers can maintain a cache of previously assigned MAC/address pairs and try to reassign them when a client requests a new address. Usually a router reboot clears that cache. Your DHCP logs will confirm the address choice was at the server, not the client. This is for new addresses, not address lease renewal. 

There isn't enough evidence, either way, to tell if the problem occurs at lease renewal time. If it did it would likely only impact the Sonos (and any downstream devices) requesting the renewal. 

Yes, that’s correct. In practice, the devices will keep the same IP address unless their DHCP lease expires at the same time as the reboot.
 

DHCP “leases” an address for a period of time. When the lease expires the client device returns to the DHCP server to “renew” the address. Depending on the DHCP server the client device may renew to same address or not. At renewal time a client might be powered down or, in the case of a portable, out of the area. Renewing to the same address would reduce many risks associated with a changing address, but how long should the DHCP server track and reserve that device address in case the device might power up or return to the area? There are lots of potential little details that could frustrate a client or two — such as a player or controller’s lease expiring and changing while an update is in progress.

Reserving IP addresses for SONOS and controller devices can prevent this nonsense. Since I have a local music library, I also reserve addresses for the NAS drives.

I suppose the renewal risk could be reduced somewhat if the SONOS update process began with a mass renewal and discovery for its own devices, but this could not guarantee that the controller device would not renew during the process.

Most devices actually retain addresses because their lease has not expired even if there is a reboot. They can do this because the programmers cache the address and lease expiry information. The primary uses of this are renewing the lease to avoid changing IP address and re-establishing connection after a reboot.

I haven't seen client machines doing this, the only cache I have seen, looking at my DHCP logs, is on the server.

Sonos doesn't do any caching that I have been able to detect, it would have to be written to NVRAM, something Sonos tries very hard to avoid due to write limits, particularly on older Sonos where it is a manor issue/failure point.

When you display the About My System tab the IP address for each speaker is displayed because the speakers have stored (cached) the information.

Now I'm confused.

How after a reboot and without connecting your speaker to the router and it being assigned an IP address do you connect to it to see the cached IP address?

‘Dynamic’, according to the actual spec in no way means it should change its IP address at reboot.

Ill informed and tireless defending are the norm though - but they certainly get the ‘Likes’.

It would be interesting though to know how compliant Sonos is to the actual DHCP standard.  So much attention is given to routers and DHCP servers etc. here - but maybe they’re just doing what they’re being asked to do?

There’s lots of comments here over the years about reservations etc. (and it definitely helps in many instances) - but why is that the case?

At reboot, does a Sonos device do a DHCPDISCOVER or a DHCPREQUEST?  It should do a DHCPREQUEST…  It is totally expected behaviour that a device requests its previous IP address
An IP Address is leased for a time and shouldn’t even be offered to another device until it’s expired - and the chances of that happening during a reboot must be sooooo small.

To be clear, while a DHCP server makes the final choice, the client absolutely does influence it and should be requesting its previous IP (per the DHCP spec!).  The server then honours that request if the lease is still valid - so no, the IP isn’t chosen blindly by the DHCP device alone…  As long as the clients are adhering to the DHCP spec that is…………………

Any device that adheres to the DHCP standard?

My home PC has had the same internal IP for years and it’s not reserved.  As has my phone and anything I just checked.  I do however, have reserved IPs for Sonos devices..

Many devices do retain their IP across reboots, and it’s completely normal. In fact, routers and operating systems are specifically designed to make that happen, because constantly changing IPs would break things like cached ARP tables, local service discovery, and connections to devices like Sonos.

There are people who have enough education and don’t want to learn anything further. Motivation is the key. When the Internet was in its infancy I suggested to people that online forums could be useful. At the time this meant a phone modem and computer. Pads and phones didn’t exist yet. People would back away and proudly declare “I don’t do that”. Then their grandchildren went online and wanted to share pictures. Suddenly these same people were proudly online. It was just motivation. Rather than being proud of not being online they were showing off the pictures. It wasn’t so hard being online after all.

Currently, there are a few things about networking that are handy to learn. Yes there is some equipment where the default configuration might do what you need, while other equipment will not. You need to at least learn which equipment to install. Unfortunately, in the mass marketplace companies can’t say “our products only work with manufacturer XYZ”. At inception in 2005 SONOS had their own wireless mesh that always worked, but having at least one wired connection was required. SONOS got pummeled in the marketplace, accused of lying about their system being “wireless”. Eventually, SONOS relented and enabled WiFi connections, eliminating the mandatory wired connection (it is now optional). Actually, it was more or less a cheap trick from a hardware standpoint, but the products then became exposed to the (often not standards compliant) WiFi implementations of other manufacturers. With a few exceptions the user can configure their WiFi to work fine with SONOS, but this requires a little learning. 

You can answer that yourself by looking at your routers DHCP logs.

As the device has no record of the address it had before the reboot it can't request it. That caching is a server function.

​@buzz 

I couldn’t agree with you more. Sonos as you said relented to the countless complaints of “their product works on my home WiFi and as a wireless product so should yours”. However, no one cares to remember (or they weren’t using Sonos) when the wireless issues of today were practically non-existent.

Education is key and the majority just refuse to admit wireless home networks are not generic overall. If they were manufacturers of network equipment and ISP’s would have no basis to say “use/buy my product instead of my competitors.

Granted they all claim certification by the Wi-Fi Alliance but that is only to say my product meets the generic threshold. After that it’s marketing anything goes and shame on you if you can’t make every home Wi-Fi device connect. So what happens… blame the equipment manufacturer. In this senario it’s Sonos.

Early in the 200x’s relatively few people were using WiFi, supporting just a couple client devices. A scan for WiFi devices wouldn’t show much. One router I encountered could support only a couple dozen IP reservations, fortunately for most users this was beyond infinity.

I recently relocated in an urban area. Last week my scan logged over 100 access points. Many of these were obviously mesh points or extenders. I don’t know how many local clients this represents. Sure, a few of these access points could be drive-by or walk-by, but this is a very low traffic secondary street. Mostly everyone is behaving themselves and are using only 20MHz channels 1-6-11, but there are a couple wise guys who are off this grid with wider channels. Fortunately, they are relatively weak and don’t seem to be bothering me.

It’s not your dad’s WiFi anymore. Anyone still using dad’s network should consider updating.

Sorry ​@Stanley_4 , that’s simply not true and is a key part of how DHCP works.  Devices can, and should, request the same IP address again.  DHCP protocol isn’t all server side, (compliant) clients play their part too.
Actually, I know AI can get things wrong - but I just asked Chat GPT for a brief explanation - hopefully it helps…

“🧠 In plain English

When a device reboots it should remember its old IP, and it should:

1. Skip the broadcast DHCPDISCOVER (asking for any IP).

2. Immediately send a DHCPREQUEST (asking for that same IP).

3. The DHCP server checks whether the lease is still valid and—if so—ACKs it, confirming the same address.

This gives stable IP behaviour without needing a static or reserved address.

If a device skips the DHCPREQUEST and starts with DHCPDISCOVER instead, it’s either:

• forgotten its previous lease,

• the lease expired,

• or the firmware simply doesn’t follow best practice.

That’s when IP churn or conflicts become more likely.”

Because the address is “leased” for a period of time so if that lease has not expired the device can continue using the IP address. There are protocols for this but ultimately a device does not have to request a new IP address after a reboot or restart it can continue using the one that has been dynamically assigned.

There are also differences between a hard (power off) or soft (restart) reboot with software updates usually being in the soft category meaning that their is an opportunity for the code to save information when shutting down that will make sure things work better when the system starts again. In a hard restart scenario the developers may choose to start from scratch and request new IP addresses as part of a “clean” start.

My guess is that Sonos adheres to the standards and that IP addresses are not typically changed after software updates. Of course they might change and that might cause problems for some users after updates. But only if some part of the eco system has the old address rather than a newly assigned one. 

My point was though that you can’t say that it is 100% certain that a Sonos software update will result in network changes. That is not a true statement.

Hi all,

We believe this thread has run its course and will be locking it from any further posts.

Please create a new thread if you’d like to keep any discussions going, we’d also request that you keep it courteous and follow the community terms and conditions.

If you have an issue with your system, then please create a separate topic where you can receive troubleshooting assistance from community members or Sonos community moderators.