We are seeing persistent ssl handshake errors running deviceOS 1.3.0-rc.1 and using MQT-TLS library version 0.2.20. The device will attempt to connect to the cloud generating handshake errors. When I flash the tinker app onto the board I do not run into this issue.
The program is running with SYSTEM_THREAD(ENABLED).
This issue occurs whenever we call particle.connect(). Yes, I am sure I am connected to WiFi and NOT connected to particle when the call is made.
I have changed the keys for the device. This fixes it for the first try, but then fails if the power is removed, on the next try.
Anybody have this issue happening with a solution?
What board are you using? You say you’re using MQTT-TLS, but talking about connecting with the Particle cloud. Which are you doing, or are you connecting to both Particle cloud and an MQTT broker?
I will say that I have seen errors recently on Boron LTE with MQTT-TLS and 1.3.0-rc.1 (SOS, 1 flash) that I don’t see with 1.2.1. I haven’t done enough investigation yet though to call it a firmware problem. Very likely could be my code.
We are using the Argon.
We are connecting to an MQTT broker to transmit data, but have some functions and variables in particle console we like to use as well.
Maybe the 1.3.1 release will clear some of this up?
I have tried a variety of things like removing the MQTT-TLS library from the code, this did not solve the problem.
I enabled the debug messages and flashed tinker to the board. The tinker firmware connected to the cloud successfully on the first try and subsequent tries if I pressed the reset button. When I pulled the power cord, the first connection ended with the same restoreStatus=2.
I then loaded @rickkas7 photon-clouddebug code for the argon. The code loop through the following debug messages 6 times.
0000044344 [comm.dtls] ERROR: handshake failed -6800
0000044346 [comm.protocol.handshake] ERROR: handshake failed with code 17
0000044348 [system] WARN: Cloud handshake failed, code=17
0000044599 [system] INFO: Cloud: disconnecting
0000044599 [system] INFO: Cloud: disconnected
0000045348 [system] INFO: Cloud: connecting
0000045350 [system] INFO: Read Server Address = type:1,domain:$id.udp-mesh.particle.io
0000045352 [system] ERROR: Failed to load session data from persistent storage
0000045354 [system] INFO: Discarding session data
0000045355 [system] TRACE: Resolving e00fce68616a896b71f4cda0.udp-mesh.particle.io#5684
0000045392 [system] TRACE: Address type: 3
0000045392 [system] TRACE: Cloud socket=0, family=2, type=2, protocol=17
0000045394 [system] INFO: Cloud socket=0, connecting to 220.127.116.11#5684
0000045396 [system] TRACE: Cloud socket=0, connected to 18.104.22.168#5684
0000045397 [system] TRACE: Updating cloud keepalive for AF_INET: 30000 -> 30000
0000045399 [system] TRACE: Applying new keepalive interval now
0000045401 [system] INFO: Cloud socket connected
0000045402 [system] INFO: Starting handshake: presense_announce=0
0000045403 [comm.protocol.handshake] INFO: Establish secure connection
0000045610 [ncp.at] TRACE: > AT+MVER
0000045641 [ncp.at] TRACE: < 5
0000045642 [ncp.at] TRACE: < OK
0000045645 [comm.dtls] INFO: (CMPL,RENEG,NO_SESS,ERR) restoreStatus=2
On the 7th run through it connected with the following messages:
0000070004 [comm.protocol.handshake] INFO: Sending HELLO message
0000070153 [comm.protocol.handshake] INFO: Handshake completed
0000070154 [system] INFO: Send spark/hardware/max_binary event
0000070156 [system] INFO: Send spark/device/last_reset event
0000070159 [system] INFO: Send subscriptions
0000070161 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000070162 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 3
0000070163 [comm] INFO: Sending TIME request
0000070165 [ncp.at] TRACE: > AT+CWJAP?
0000070202 [ncp.at] TRACE: < +CWJAP:"wifiNetwork","34:fc:b9:84:8a:c4",6,-36
0000070204 [ncp.at] TRACE: < OK
0000070205 [comm.protocol] INFO: Posting 'M' describe message
0000070207 [comm.protocol] INFO: rcv'd message type=1
0000070208 [system] INFO: Cloud connected
connected to the cloud!
What is happening on the power down with the persistent data that gets in the way of a reconnect?