Skip to main content
I have a ZP100 that has updated to 8.1 but will not register. I get a time out with the message "Setup Problem Check your internet connection and that all your players are plugged in".



I have tried the registration process with this player many times over the last 2 weeks. Other players (ZP100s among them) have not had this issue.



Here are the contents of anacapa.trace after I try to register:



[2000-01-01 00:47:01.810] Validating flags [0x00000001] for endpoint [/device_account/registration]

[2000-01-01 00:47:01.814] perf: 1: ip=169.254.1.100:60880, sidx=1, backlog=0, total=477, sm=0, fb=473, req=473, handler=477, cm=477, op=https

[2000-01-01 00:47:03.820] timedjobmgr starting job "pollZPHighRateJobs" (s:946687623 n:946687623)

[2000-01-01 00:47:03.825] timedjobmgr completed job "pollZPHighRateJobs"

[2000-01-01 00:47:06.830] timedjobmgr starting job "fetchRegDeviceCert" (s:946687626 n:946687626)

[2000-01-01 00:47:06.831] regcert: fetching certificate []

[2000-01-01 00:47:06.871] took 38ms for (1) registration.ws.sonos.com

[2000-01-01 00:47:06.871] registration.ws.sonos.com -> 23.206.196.30

[2000-01-01 00:47:06.892] using client cert [0]

[2000-01-01 00:47:06.893] registration.ws.sonos.com cache load

[2000-01-01 00:47:06.894] registration.ws.sonos.com cache hit: [7]

[2000-01-01 00:47:06.894] initiating SSL connection to registration.ws.sonos.com

[2000-01-01 00:47:06.935] using local-only mode cert validation for registration.ws.sonos.com

[2000-01-01 00:47:06.968] local cert validation succeeded for registration.ws.sonos.com

[2000-01-01 00:47:07.357] connected to registration.ws.sonos.com using TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384

[2000-01-01 00:47:07.358] registration.ws.sonos.com cache store hit: [7]

[2000-01-01 00:47:07.358] registration.ws.sonos.com cache stored [7]

[2000-01-01 00:47:07.622] First Response: [registration.ws.sonos.com] [Regis] [00000000] [401]

[2000-01-01 00:47:07.625] registration.ws.sonos.com -> 23.206.196.30

[2000-01-01 00:47:07.657] using client cert [0]

[2000-01-01 00:47:07.658] registration.ws.sonos.com cache load

[2000-01-01 00:47:07.658] registration.ws.sonos.com cache hit: [7]

[2000-01-01 00:47:07.659] initiating SSL connection to registration.ws.sonos.com

[2000-01-01 00:47:07.692] connected to registration.ws.sonos.com using TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384

[2000-01-01 00:47:07.693] registration.ws.sonos.com cache store hit: [7]

[2000-01-01 00:47:07.693] registration.ws.sonos.com cache store hit: id match

[2000-01-01 00:47:07.913] HTTP Result: HTTP/1.1 403 Forbidden

[2000-01-01 00:47:07.914] Second Response: [registration.ws.sonos.com] [Regis] [00000000] [403]

[2000-01-01 00:47:07.915] UsageMetrics: deviceCert adding 168 bytes, 4032 free

[2000-01-01 00:47:07.915] regcert: failed to fetch file (-7 403). Elapsed=1083ms, current eTag=''

[2000-01-01 00:47:07.917] registration error



I submitted diagnostics with confirmation number 8071582.



Thanks!
I'm not an expert, but one thing in that log looks weird to me. Why is there a 169.254. (Zeroconf) IP address shown? Does your ZP100 have a normal, private IP address?
Thanks for your reply. I have a subnetwork with that IP address range for troubleshooting.
Technically that is not a valid subnet, as you're using zeronconf IPs. As they are special in networking, I'd recommend to use a proper network in valid IP range. Giving out auto IPs to devices manually might lead some strange behavior, like you have it now.
I see what you're saying and that makes sense. However, this player exhibits the same behavior even in a different subnet (my home network is 192.168.1.xxx) so I don't believe this is the root issue.
I have the same issue: The Play One refuses to 'register' although the other two devices, which are on the same wireless network, had no trouble.
Well, I just fixed the problem. My Sonicwall firewall, which does an EXCELLENT job with network security and is configured for deep packet inspection (DPI), was blocking part of the two-way traffic between the Sonos site and the device because of content. Meanwhile, there were no stateful packet inspection drops by the firewall (why I was initially puzzled). Momentarily disabling DPI allowed the registration to finish. Lesson-learned: Check ALL firewall settings and security configurations.