Sonos not working - error 1002 when playing spotify, error 1101 when updating

1. Get the IP address of a Sonos device (A.B.C.D) from Settings/System/About.
2. Point a browser to http://A.B.C.D:1400/tools
3. In the top box enter sonos.com then hit Ping

If the pings fail then the system can’t connect out.

Now that it is 2022 Sonos decides to behave in the weekends as well, got to love those new year resolutions.

In all seriousness, my system now appears to be working fine. Fingers crossed that it will stay this way. 
 

Currently my network is setup the way I want it to be: 

• modem/router has everything set to default, 2.4/5Ghz WiFi broadcasting on same SSID, automatic channel selection, etc.
• Time Capsule in bridge mode, broadcasting same SSID WiFi network, automatic channel selection.
• Pi-Hole running and working, I removed Sonos from Pi-hole its whitelist again, still Sonos is working oke :)

It is difficult to say if it is just luck that it is now working fine again, or if it is due to something I changed. Last week I was playing around with some of Pi-Hole its settings, and in the end updated the system. I think I returned all settings to how they were, but maybe not. 
 

So could be that the system updates fixed whatever issue I was having, or one of the Pi-Hole settings is different from what it was before, or maybe my bad luck with the Sonos system is over. 
 

In any case, it looks like the issue is fixed for now. I’ll update this thread if the issue returns. Thank you for all the replies and support Ken. And I will try the ping action as suggested by ratty if the issue ever returns.

If it’s okay now, I would perhaps consider fixing the WiFi channels on your devices to all use the same channel & set a 20Mhz channel-width on the 2.4Ghz bands.

Unfortunately the same issue already returned, I quickly played around with the tools page that @ratty suggested. It is a very helpful page, finally some real troubleshooting tools, thanks for that!

When using a web address (e.g. Sonos.com, or Google.com) in the ping field I get a “bad address” message, but when I use an IP address (e.g. 1.1.1.1 or 8.8.8.8) it works; 0% packet loss. 
 

Based on that I believe the issue must be DNS related and not Wi-Fi settings or something. Now I am still left with the question how it can be that the Sonos system has issues with DNS, but I can still without issues access internet, use steaming services, etc.

Any ideas?

Try sonos.com in the Nslookup box. That would confirm a DNS failure. 

Output:

Sonos.com: dns (20020 ms) -> failed mdns (0 ms) -> failed netbios (0 ms) -> failed
 

When I hit the “mDNS Announce” button I get a “success” message.

And your local DNS is the Pi-hole, correct?

Yes correct, both preferred and alternative DNSv4 and DNSv6 point to the Pi-Hole. 

Well surely there’s your problem, as originally suggested. For some reason the Sonos devices are not happy with the DNS, or the DNS isn’t happy with the Sonos. 

To get deeper into the Sonos side would need a fuller diagnostic, to which users no longer have access. (There used to be a form of ipconfig and netstat, for example.) Maybe the Pi-Hole logs could indicate whether it’s unhappy? With the x.x.x.x:1400/tools Nslookup option you have the ability to query it at will. 

What seems rather odd in this case (to me at least), is the random way that things work one minute and then stop working the next, like something is scheduled and causing the failure mostly at weekends, for example, (albeit not entirely exclusively I imagine). Really odd, I thought, particularly as all other internet access was apparently still working okay with it seemingly only affecting the Sonos system?

I went looking to see if the pi-hole and it’s rules might do some kind of ‘temporary’ blocking if a ‘request’ threshold was perhaps (b)reached etc; but couldn’t find anything that might throw any light on that either. The things I read were, if a domain was put on a blocked list, it stays blocked until manually removed, or white-listed. 

If multiple domains fail to resolve from the /tools page then it suggests that either the client station (not the domain) is being blocked or the DNS interaction is in some way broken. That’s assuming of course that the Pi-hole is being supplied as DNS by the DHCP server, which one assumes to be the case. 

@ratty , the issue being DNS resolution is more specific than just putting the entire blame on pi-hole. But yes, I agree, it is now clear that the issue is in DNS resolution, and the pi-hole handles that.

I tried setting the DNS server back to default in my modem/router but it looked like I could not get my devices to update their DNS server, they still showed the pi-hole IP address. I then returned my modem/router DNS server to the pi-hole IP address, and went into pi-hole settings and set all IPv4 and IPv6 upstream DNS servers to cloudflare. Now the problem seems to be fixed again.

@Ken_Griffiths , I also find it very odd that the issue is intermittent, and mostly occurring in the weekends. Furthermore, whenever the issue happened I did not suffer from a general internet outage, it appears to have been Sonos specific, which makes it even more odd.

Summary:

• 1002/1101 (intermittent) issues caused by not being able to resolve DNS.
• Issue was not caused by any internal network or connection issues: in my specific case it is perfectly fine to have 2.4Ghz and 5Ghz WiFi broadcasting the same SSID, having a guest network enabled was also not the problem, neither was it to have a WiFi extender broadcasting the same SSID, and automatic channel selection is also ok.
• Pi-Hole in general does not interfere with Sonos at all. In my case I only have the default block lists which is fine to use in combination with Sonos. What (looks to have) caused the issue is using cloudflared DoH, or at least my implementation of it. The moment I changed the upstream DNS servers in pi-hole its settings from the custom cloudflared one to the normal cloudflare one my Sonos system came back to life. I do not understand the reason for this, but I also believe it is outside the scope of this forum.

@Ken_Griffiths , @ratty , thank you guys for the support, you are obviously very knowledgeable with respect to how Sonos works, and I appreciate the help. Having said that, I really think Sonos needs to work on providing more explanation to error codes, and be of better help in troubleshooting. The provided error codes are just that, codes, without any further information. A user is more or less forced to revert to the Sonos forums for understanding the issue and getting support, further amplified by the fact that Sonos customer service has been very poor, only being able to provide the very basic steps and throwing in the towel afterwards. At some point I even asked a Sonos customer support person if there are any troubleshooting tools available to users that may help to further understand the issue, to which they simply replied no.

Turns out, after a lot of googling and suggestions in this thread, that such tools are in fact availabe to users (see below).

Useful tools for any reader that is also struggling with their system:

• http://x.x.x.x:1400/tools
• http://x.x.x.x:1400/support/review
• http://x.x.x.x:1400/status/proc/ath_rincon/status

Those errors codes are pretty generic, indicating a failure to get a response. There are in fact help pages on support.sonos.com. They’re mostly framed in the context of firmware updates, but can be extrapolated to other situations. 

It’s tricky. Trying to automate troubleshooting by providing more information could lead the less well informed users down blind alleys -- a little knowledge can of course be dangerous -- which is why Sonos advocate submission of a system diagnostic and consulting them. The diag contains copious status info and logs.  

This is indeed disappointing. First line phone support these days seems to work to scripts that only cater for ‘standard’ cases. Pretty much by definition someone who messes around with their network and redirects DNS requests is no longer ‘standard’. Had you persisted and demanded escalation it’s possible that you’d have eventually encountered more bespoke assistance at higher support tiers. 

It’s hardly surprising that first line support don’t resort to these tools. They’re unsupported, and therefore subject to change or withdrawal. Indeed up to a few years ago the /support/review (and /status) pages provided access to a veritable cornucopia of diagnostic information, which allowed some of us earlier adopters to figure out a fair bit about what was going on.

@matha,

From the link to cloudflared you posted earlier…

… I’m not familiar with the DNS over https software, but just wondered if this might be relevant to your setup and to maybe try the earlier version mentioned (if not using that already, of course?)

Yes I also noticed that part, but I am using a 3B+, so it should not be relevant. It does not hurt to give it a try somewhere down the line though.