Hello everyone!

​@Hulla 

That’s the problem a lot of members like yourself think that a community is only to report issues or complaints. That’s not the sole purpose. You can provide posts on what you find positive as well. Maybe suggest a feature request or report a positive discovery made that is useful to others as Sonos is very versatile.

Also, be sure to read the EDIT to my previous post.

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?

Right, it's clear that there are some incredibly diligent and knowledgeable people on these forums, some that are a bit cultish (and might be encouraged to spend more time with their families if everything is so rosy - and less on internet forums), and some that are useful, which are appreciated.

Let's not lose sight of the fact that we're just talking about 'Speakers' here. Sonos are required to make a speaker that does what they advertise it to do - without too many complications for the 'common user'. Nothing more. The fact that they don't do that, is why people are complaining.

I hate to be judgemental though but honestly, what's going on in your life that you are logging onto a forum on 'speakers' in your free time when your system is working fine?

Surely you'd just be smugly listening to HD music, as apart from telling people they're wrong, suggesting ideas that they've clearly already tried or belittling then for asking for an alternative; you've all been useless. 

Thanks, that has been one of my life's major goals.

We told you to go buy Bose several times now.  So instead of questioning our presence on this forum, ask yourself exactly why you are still here?

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