SOLVED: "Error claiming the device. Could not claim the device to your account"

Continuing the discussion from RPi 1 Model B USB root hub becomes permanently disabled after step "Claiming device":

After getting a RPi 2 B up and running, and re-running the install script, I am faced with this error:

Error claiming the device. Could not claim the device to your account.

I’ve tried rebooting it, reinstalling, etc; and I can confirm positively that I am using the account that was granted Beta access (I only have one account, anyway…)

Any help?

1 Like

@legoguy
What are you naming the device in particle-agent? If you already have a claimed device named “pi”, you can not reuse the name.

Unclaim other raspberry pi’s or name it differently.

I had this issue as well.

I named it something unique; I figured it wouldn’t have successfully claimed any of my previous attempts (what with the network dropping); indeed, they do not show up in the list of my devices in Console for me to “unclaim”!

Strange. Does the /var/lib/particle/settings.json file exist, and does it have a generated device ID inside?

Indeed it does exist, and contains everything you might expect it to.

What if you try to claim that ID in particle-cli?

I get a very unhelpful message:

Claiming device [...]
Failed to claim device, server said: [object Object]

Ping @jvanier

I tried sudo particle-agent logs and some interesting things show up:

0001403656 system: INFO: Cloud: connecting
0001403656 system: ERROR: connection failed to 0.0.0.0:5683, code=111
0001403656 system: INFO: Cloud socket connected
0001403656 comm: WARN: receive error -1
0001403656 comm: ERROR: Handshake: could not receive nonce: -1
0001403656 comm: WARN: handshake failed with code 2
0001403657 system: WARN: Cloud handshake failed, code=2
0001403907 system: INFO: Cloud: disconnecting
0001403907 system: INFO: Cloud: disconnected

(repeated many, many times)

I wonder why the Pi is trying to connect to this IP.

This sounds like a DNS problem to me. By the way 111 means connection refused.

I just updated to the latest version of particle-agent and I can no longer SSH into my Pi.

Here is what happens when I try right after reboot:

nrobinson@particle.local's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Nov 24 15:40:53 2016 from 2604:6000:8680:d300:1487:c185:f414:bb3e
-bash: /home/nrobinson/.bashrc: Input/output error
Connection to particle.local closed.

And if I try again:

Connection reset by 2604:6000:8680:d300:2cd3:eddd:805c:2b74 port 22

I’m going to try booting with a monitor.

Update:
I can now SSH again. Weird.

So that I can further investigate this, what is the DNS name that the agent connects to? everything else on my network is handling DNS just fine. I’ll try today on a totally different network and see if it makes a difference.

It connects to YOUR_PI_DEVICE_ID.agent.particle.io

You can test the DNS by doing

dig YOUR_PI_DEVICE_ID.agent.particle.io

in a terminal.

There are several different IP’s that you can get.

Okay, that resolves to one of the Spark nodes with dig and nslookup, so the DNS part appears to be working… though the logs are still showing 0.0.0.0.

What if you try the installer again?

bash <( curl -sL https://particle.io/install-pi )

No joy. I’m now looking for part of the particle-agent source code that’s generating those log lines so I can backtrack and debug, but they are unusually elusive…

I’m looking deeper into the logs and I’m finding this:

0000000004 system: INFO: Device 7ab717a71de432a31bcbe174 started
0000000004 hal: INFO: Virtual WLAN init
0000000004 system: INFO: ready():false,connecting():false,listening():false
0000000004 hal: INFO: Virtual WLAN on
0000000004 hal: INFO: Virtual WLAN connecting
0000000005 hal: INFO: Virtual WLAN connected
0000000006 hal: INFO: device key: (an actual valid key)~
0000000006 hal: INFO: server key: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000~
0000000006 system: INFO: Cloud: connecting
0000000007 system: ERROR: connection failed to 0.0.0.0:5683, code=111
0000000007 system: INFO: Cloud socket connected
0000000008 comm: WARN: receive error -1
0000000008 comm: ERROR: Handshake: could not receive nonce: -1
0000000008 comm: WARN: handshake failed with code 2
0000000009 system: WARN: Cloud handshake failed, code=2
0000000259 system: INFO: Cloud: disconnecting
0000000264 system: INFO: Cloud: disconnected

So two things come to mind: 1 - why is the server key 0000…, as I checked /usr/share/particle/keys/server_key.der and there is definitely one there, and 2 - this turns out to be the actual firmware (tinker) that is reporting errors, not the particle-agent itself.

Also worth it to note that I am now on a totally different network with the same results. No other DNS issues on any other devices (though I think my earlier post already put that possibility to bed)

Are you sure the /usr/share/particle/keys/server_key.der is intact?

Here is what I get for the md5sum.

5c8c2370820fe5fcfd00a08e504524a7  /usr/share/particle/keys/server_key.der

Yes, that matches mine.