Skip to main content

Hi all,

 

I’ve come here to share some grievances that my pair of (stereo-setup) One SLs give me. After some time (usually a few days), both speakers decide to ignore DHCP offers from my DHCP server and start to setup their own, isolated, and unreachable, network in the 169.254.0.0/16 LINKLOCAL-RFC3927 space. Restarting the speakers does not help, only disconnecting from the WiFi and reconnecting makes them accept DHCP offers again.

 

Obviously, ignoring DHCP offers and resorting to an isolated enclave is not an appropriate mechanism for a network-only speaker. I’d be eager to hear from Sonos what they suggest to be done here.

 

cheers,

--m

 

p.s. happy to provide pcap’s that clearly illustrate the issue at hand.

I’d start with the wireless interference FAQ.

https://support.sonos.com/s/article/3286?language=en_US

 

I’d also set static/reserved IP addresses for all my Sonos gear to avoid any DHCP reassignment issues.

Thanks Stanley_4. There’s pristine WiFi connection between my Sonos’ and the AP (only a few feet apart, with no obstructions)

 

The DHCP server is configured to hand out fixed IPs for the Sonos speakers. Every few minutes the Sonos send a DHCP-Discover message to see whether they can get the same IP again. Of course they can, the IPs are designated in the DHCP server and the lease time is 24hrs. So whatever the setup of the DHCP client in the Sonos is, it seems overzealous at least, and seizes to work after some time completely.

In 8 years on the forum I have never come across this issue, and so I very much doubt this is a generic issue with Sonos. 

I (somewhat) completely agree that this is not a generic issue (someone else would have run into it before me). I’m looking for ideas on how to debug my very personal issue.

 

I say somewhat above, as the dhcp client (according to my network captures) clearly re-requests IP leases according to an exponentially decaying schedule (e.g., 90 45 22 11 6 3 minutes), ignoring the lease-time provided by the DHCP server (24hrs). By itself not a problem, but I’m pretty sure it’s not the behavior intended by the DHCP protocol.

 

Either way, if someone has advice on how to debug this issue, I’m all ears.

Where is the DHCP server running? For Sonos to reject the offer it may be non-standard. 

The fallback to an AutoIP island, linked by SonosNet, in the absence of assigned IPs is expected behaviour. 

The DHCP server runs on my gateway machine. My current hypothesis is that the Sonos does not set the Broadcast flag in DHCP DISCOVER messages. Which the DHCP server obliges and sends a unicast DHCP OFFER --- if Sonos cannot use unicast messages before an IP was assigned, than that might explain the behavior. I configured the DHCP server to force DHCP OFFER messages to the Sonos speakers as broadcast and will monitor whether this has impact on the the sporadic behavior I’m observing.

Just to follow up on this, in case someone runs into a similar issue.

After configuring my DHCP server to send DHCP OFFERs to the Sonos devices on my network via broadcast unconditionally (although the dhcp client in Sonos claims it can handle unicast OFFERs), seems to have resolved the issue. At least I didn’t observe any of the previous misbehaviors during the last 9 days.

 

@Sonos, if you can confirm that your speakers cannot accept unicast DHCP OFFER messages, it would bring the client into protocol compliance if it indicated as much by setting the bootp broadcast flag.

Terms & ConditionsCookie settings