Cloud connection error: connects to wifi, then blinks cyan then single red blink, then cyan ("Cloud handshake failed, code=-19")

Troubleshooting
1

Hello,

I am using a P1 on a custom PCB, running 0.6.1 firmware, and seeing a cloud connection error very similar to norstar’s: (https://community.particle.io/t/photon-green-cyan-red/30761), except that the status LED blinks red once instead of orange before reverting back to cyan.

The P1 will not enter safe mode (no cloud connection), and I have tried “particle keys doctor DEVICE_ID” using the CLI:

[CODE]
D:\Dir2\tests>particle keys doctor DEVICE_ID
running dfu-util -l
Found DFU device 2b04:d008
running openssl genrsa -out DEVICE_ID_new.pem 1024
running openssl rsa -in DEVICE_ID_new.pem -pubout -out DEVICE_ID_new.pub.pem
running openssl rsa -in DEVICE_ID_new.pem -outform DER -out DEVICE_ID_new.der
New Key Created!
running dfu-util -l
Found DFU device 2b04:d008
running dfu-util -l
Found DFU device 2b04:d008
running dfu-util -d 2b04:d008 -a 1 -s 34:612 -U pre_DEVICE_ID_new.der
running openssl rsa -in pre_DEVICE_ID_new.der -inform DER -pubout -out pre_DEVICE_ID_new.pub.pem
Saved!
checking file DEVICE_ID_new.der
spawning dfu-util -d 2b04:d008 -a 1 -i 0 -s 34:leave -D DEVICE_ID_new.der
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device…
ID 2b04:d008
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #1 …
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000022, size = 610

Download [ ] 0% 0 bytes
Download [ ] 0% 0 bytes
Download [=========================] 100% 610 bytes
Download done.
File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Saved!
attempting to add a new public key for device DEVICE_ID
submitting public key succeeded!
Okay! New keys in place, your device should restart.
[/CODE]

but the P1 still does not connect to the cloud (blinks cyan, then single red blink, then back to cyan).

Using the photon-clouddebug combined-p1.bin (https://github.com/rickkas7/photon-clouddebug, thanks to rickas7 for posting!), I see the output:

SSID=CON_NET security=wpa2 channel=8 rssi=-64 connecting to WiFi 0000007037:INFO : virtual void ManagedNetworkInterface::connect(bool) (282):ready():false,connecting():false,listening():false connected to WiFi! localIP=192.168.1.78 subnetMask=255.255.255.0 gatewayIP=192.168.1.254 dnsServerIP=0.0.0.0 (often 0.0.0.0) dhcpServerIP=0.0.0.0 (often 0.0.0.0) ping gateway=1 ping addr 8.8.8.8=1 device.spark.io=54.221.65.123 0000009002:DEBUG: virtual void TCPClient::stop() (192):_sock -1 closesocket 0000009002:DEBUG: virtual int TCPClient::connect(IPAddress, uint16_t, network_interface_t) (80):socket 536895952 0000009003:DEBUG: virtual int TCPClient::connect(IPAddress, uint16_t, network_interface_t) (98):_sock 536895952 connect 0000009092:DEBUG: virtual int TCPClient::connect(IPAddress, uint16_t, network_interface_t) (100):_sock 536895952 connected=1 connected to device server CoAP (testing connection only) 0000009092:DEBUG: virtual void TCPClient::stop() (192):_sock 536895952 closesocket 0000009093:DEBUG: sock_result_t socket_close(sock_handle_t) (939):socket closed 200061d0 connecting to cloud 0000009093:INFO : void establish_cloud_connection() (214):Cloud: connecting 0000009093:DEBUG: int spark_cloud_socket_connect() (834):sparkSocket Now =-1 0000009094:DEBUG: int spark_cloud_socket_connect() (853):HAL_FLASH_Read_ServerAddress() = type:255,domain:,ip: 0.0.0.0, port: 0 0000009126:INFO : int determine_connection_address(IPAddress&, uint16_t&, ServerAddress&, bool) (803):Resolved host device.spark.io to 52.90.147.116 0000009126:DEBUG: int spark_cloud_socket_connect() (864):socketed udp=0, sparkSocket=536895672, 1 0000009127:DEBUG: int spark_cloud_socket_connect() (874):connection attempt to 52.90.147.116:5683 0000009215:INFO : int spark_cloud_socket_connect() (891):connected to cloud 52.90.147.116:5683 0000009216:INFO : void establish_cloud_connection() (221):Cloud socket connected 0000009216:DEBUG: int Spark_Handshake(bool) (546):starting handshake announce=1 0000009308:DEBUG: int read_packet_and_dispose(tcp_packet_t&, void*, int, wiced_tcp_socket_t*, int) (792):Socket 0 receive bytes 40 of 40 0000009345:DEBUG: sock_result_t socket_send(sock_handle_t, const void*, socklen_t) (1002):Write 256 bytes to socket 536895672 result=0 0000009435:DEBUG: int read_packet_and_dispose(tcp_packet_t&, void*, int, wiced_tcp_socket_t*, int) (778):Socket 0 receive fail 19 0000009436:DEBUG: sock_result_t socket_receive(sock_handle_t, void*, socklen_t, system_tick_t) (824):socket_receive on 536895672 returned -19 0000009436:ERROR: int SparkProtocol::handshake() (108):Handshake: Unable to receive key -19 0000009437:WARN : void handle_cloud_connection(bool) (268):Cloud handshake failed, code=-19 0000009687:INFO : void cloud_disconnect(bool) (427):Cloud: disconnecting 0000009687:DEBUG: int spark_cloud_socket_disconnect() (912):Close Attempt 0000009687:DEBUG: sock_result_t socket_close(sock_handle_t) (939):socket closed 200060b8 0000009688:DEBUG: int spark_cloud_socket_disconnect() (914):socket_close()=success 0000009688:INFO : void cloud_disconnect(bool) (440):Cloud: disconnected ... (output repeats)

What does “Cloud handshake failed, code=-19” mean?

Thank you.

2

Did you also do:

particle keys server

in DFU mode?

You might have a bad server public key if your device key was bad, and that will fix it. If that doesn’t fix the problem, you can PM your device ID or create support ticket and I can check the cloud logs.

3

Hello @rickkas7,

I had not tried “particle keys server”. What argument should I enter for the server key?

D:\Dir2\tests>particle keys server Please specify a server key in DER format.

4

You should update your Particle CLI. The current version is 1.21.0.

For Windows, the best way is to update using the Windows CLI installer. The instructions and links to it are here.

The current versions of the CLI don’t require an argument and will set the correct production server key automatically.

1 Like
5

Thank you. After a small odyssey, I was able to update node.js and Particle CLI.

I put the P1 in DFU mode and ran “particle keys doctor”:

[CODE]
D:\Dir2\tests>particle keys doctor DEVICE_ID
Found DFU device 2b04:d008
Found DFU device 2b04:d008
New Key Created!
Found DFU device 2b04:d008
This file already exists, please specify a different file, or use the --force flag.
Continuing…
spawning dfu-util -d 2b04:d008 -a 1 -i 0 -s 34:leave -D DEVICE_ID_rsa_new.der
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device…
ID 2b04:d008
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #1 …
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000022, size = 608
Download [=========================] 100% 608 bytes
Download done.
File downloaded successfully
Error saving key to device…
Make sure your device is in DFU mode (blinking yellow), and that your computer is online.
Error -

D:\Dir2\tests>
[/CODE]

The “Error saving key to device…” is a message I have not seen before.

Then I ran “particle keys server”:

[CODE]
D:\Dir2\tests>particle keys server
Found DFU device 2b04:d008
spawning dfu-util -d 2b04:d008 -a 1 -i 0 -s 2082 -D D:\AppData\Roaming\npm\node_modules\particle-cli\keys\rsa.pub.der
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device…
ID 2b04:d008
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #1 …
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000822, size = 512
Download [=========================] 100% 512 bytes
Download done.
File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Okay! New keys in place, your device will not restart.
[/CODE]

I then reset the P1, the P1 connects to WiFi, but then goes back to the same cycle of status LED cyan-single red blink-cyan.

Should I submit a support ticket?

6

Yes, go ahead and submit a support ticket with the output from the Photon cloud debug, not redacted. Actually, if you could use the combined.bin method of flashing that produces more output which might also be helpful.

Rick

7

I have the exact same problem now. I have a custom PCB based on a P1. The PCB sits in a prototype that have been working for about a week. Yesterday evening it suddenly started to blink Blue (Setup mode) for no apparent reason.

After giving it the same Wifi credentials it had before, it now blinks Cyan several times and then a single red blink. The machine is fully functional, but since it’s not cloud connected, I cannot update it. I can probably flash it via USB, but then I’d need to setup a full local environment (I’d rather not).

How can I resolve this and prevent it from happening in the future? I need the machine to be 100% stable before we start selling them…

1 Like
8

@shm45 did yours also loose it’s wifi credentials when this happened?

9

What do you consider a full local environment?
The red flash might indicate a keys issue but also be something else.
A video might help clarifying.

If it's a keys issue, you'd need CLI with DFU drivers and OpenSSL which might be there already, depending on OS.

BTW, 0.7.0 should bring some "self healing" features for some of the "common amnesia" issues.

10 
What do you consider a full local environment?

Just something that would let me make a .bin file that I can Flash? From what I’ve seen, you need to setup a full toolchain with GCC and all to build locally, but maybe I can build in the cloud and get the BIN back for me to Flash locally?

Here is a video of the problem https://www.youtube.com/watch?v=PYOZEoIIyDk
Eventually it will quit the red blinks and just do white ones.

I’m om OSX, so I have OpenSSL installed and I have DFU utils as well. Self healing sounds like a great thing, as this cannot happen after we distribute these machines all over the world. Will be too expensive to travel around Europe to reflash machines…

11

Nope, you can build in the cloud with Particle Dev and CLI and they will automatically download the binary or you can even build in Web IDE and then download the binary manually by clicking the cloud symbol next to the project name.

And flash it via CLI.

BTW, that red flash doesn't look like the typical key issue burst.
I've seen such symptoms with power supply issues tho'

@rickkas7, any suggestions?

12

It could be a keys issue, given how quickly it fails I would guess a server address failure. It could also be a DNS issue. The cloud debug log would say for sure.

If you have a USB port for the P1, there are instructions for flashing it using dfu-util. If you have access to D6 and D7 for SWD and the TX pin, there’s also a version that can be programmed by JTAG/SWD and outputs the data through the serial port instead at the link above.

2 Likes
13

It took quite some time to get the board disconnected so I could work on it, but I followed the steps that @shm45 used and now the board is back in business. I did the two commands here:

particle keys doctor DEVICE_ID
particle keys server

and then it was back in business. This worries me a bit though… How often can this happen in the field?

14

Hello @jenschr,

Low power input to the P1 seems to cause the loss of Particle keys on the P1. Our custom PCB is powered by either 9V DC from a 120V AC / 60 Hz converter, or from 4 AA NiMH batteries. When on battery power, if the batteries are not recharged in time, we have seen about 15 units display the cyan-red-cyan blink pattern. Our current plan is to have users send the units back to us so that we can run the keys doctor via DFU over USB.

1 Like