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.