Hi,
I have just purchased an Argon and a Xenon to experiment with Particle.io and related technologies. Unfortunately I am unable to connect the Argon to the cloud. I have entered the Wifi credentials then the device blinks a few times green, then enters a never ending loop of medium speed cyan blinking - fast cyan blinking - one red blink - medium speed cyan - fast cyan - one red … I have never experienced the state that you call “cyan led breathing”. I have tried it on three different Wifi networks with the same results. I am not sure at all if it is a Wifi problem, more like that the Particle Cloud server is not recognizing my device?
Note that I am able to interact with the device via USB, including local firmware update etc.
Anyone has any clue what is wrong?
Can you try putting your device in DFU Mode (blinking yellow) and run these commands
particle keys doctor <insertYourDeviceID>
particle keys server
You can find your device ID by putting the device in Listening Mode (blinking blue) via
particle identify
Just for completeness
- you should be on the lates version CLI (currently 2.0.0) - if not run
particle update-cli - you should run the lates stable device OS version (currently 1.4.4) - if not on that run
particle update -v
I have tried these already, but did it just one more to show the output:
bash-4.4$ particle keys doctor e00fce68e48f4cbd28d27328
New Key Created!
Saved!
Saved!
attempting to add a new public key for device e00fce68e48f4cbd28d27328
submitting public key succeeded!
Okay! New keys in place, your device should restart.
… here the device has left DFU mode so I had to put it again to DFU to continue…
bash-4.4$ particle keys server
Okay! New keys in place, your device will not restart.
… at this point after pressing reset to force device to leave DFU, it has imeediately started its death dance with the cloud, green blinking, cyan blinking, red blinking and again from cyan.
I could not figurer out anything from this 
Also the device is on the latest firmware:
bash-4.4$ particle identify
Your device id is e00fce68e48f4cbd28d27328
Your system firmware version is 1.4.4
Can you share a video (30+ seconds) of the pattern?
Here is a full cycle after I pressed the RESET button The cycle repeats after the red blink, that is 5 seconds before the video ends. Then it repeats from cyan. The green blinking period happens only once after reset.
This looks like the 1 red blink described here
https://docs.particle.io/tutorials/device-os/led/photon/#red-blink-basic-errors
What alternative WiFi networks have you tried?
Have you removed all WiFi credentials before trying an alternative network?
You could try flashing this simple sketch and see what output you get via `particle serial monitor --follow
SYSTEM_MODE(SEMI_AUTOMATIC)
SerialLogHandler logger(LOG_LEVEL_ALL);
void setup() {
Log.info("Switching on WiFi");
WiFi.on();
Log.info("Spinning up WiFi connection");
WiFi.connect();
if (!waitFor(WiFi.ready, 60000)) Log.warn("WiFi timed out");
Log.info("Spinning up cloud connection");
Particle.connect();
if (!waitFor(Particle.connected, 60000)) Log.warn("Cloud not reachable");
}
There should be extra log entries by the system. If not, you may need to use Particle Workbench to build a device OS with debugging enabled and then run this again.
Thanks. This is what I see (I have discarded the parts that IMHO less important):
0000010339 [system] INFO: Cloud socket connected
0000010340 [system] INFO: Starting handshake: presense_announce=0
0000010342 [comm.protocol.handshake] INFO: Establish secure connection
0000010546 [ncp.at] TRACE: > AT+MVER
0000010581 [ncp.at] TRACE: < 5
0000010581 [ncp.at] TRACE: < OK
0000010584 [comm.dtls] INFO: (CMPL,RENEG,NO_SESS,ERR) restoreStatus=2
0000055589 [comm.dtls] ERROR: handshake failed -6800
0000055591 [comm.protocol.handshake] ERROR: handshake failed with code 17
0000055592 [system] WARN: Cloud handshake failed, code=17
0000055843 [system] INFO: Cloud: disconnecting
0000055844 [system] INFO: Cloud: disconnected
I have searched the forums for “code 17 error” and found this forum entry. I have made an attempt to downgrade to deviceOS 1.2.1 but I just got red blinking LED “SOS 10”. Then I switched to deviceOS 1.3.1, that is showing the same signs as 1.4.4 (very same code 17 error on the serial terminal after using your debug code). Then I have again “doctored” the keys and synched to the server, but the result is still the same.
Also on the question of alternative Wifi networks:
Tried two local 2.4GHz networks with WPA authentication, but very ordinary letters+numbers key. Also tried to initiate a hotspot from my iphone, result did not change.
I have no idea how to erase the credentials from the device, I presumed that it is just storing the last one?
I think this is now a state where a support.particle.io ticket is the best way forward (make sure to reference this thread here).
Maybe @rickkas7 can chime in too.
Did you do the
particle keys server
step in DFU mode? It looks like the server public key is invalid, which is not fixed by particle keys doctor.
Your keys doctor looks completed successfully on the cloud side. If you had bad device keys (particle keys doctor) that would be logged, but it’s not, so that’s probably not the issue. However if you have a bad server public key, that’s not logged, as it happens during TLS authentication, so it gets rejected by the device before it can be logged on the cloud side.
If you did do particle keys server, then definitely submit a support ticket.
I have performed the ‘particle keys server’ too, several times before but now I did it one more time. There is no change in the behavior.
I have submitted a ticket, let’s see if they can identify the problem. Thanks for the help @ScruffR and @rickkas7.
All right, I have found part of the problem. I have an ordinary Cisco cable modem at home with builtin firewall. When I turned off the firewall, the Argon device was able to connect and I can observe the slowly pulsating cyan LED.
I have yet to understand what is special in the MBEDTLS itself or in its usage in deviceOS that makes impossible to go through the firewall. This firewall has been enabled since, like two years without having any problems with any other secure network connection. Could it be a non standard port? Or the handshake protocol of deviceOS is non standard so the firewall is dropping it? From the source code I suspect that this is a DTLS UDP connection on port 5684. Can someone confirm this?
That was why I asked about the alternative WiFi networks and when you mentioned you mobile hotspot from your iPhone I dismissed the thought as these usually don’t impose such firewall restrictions.
UDP/TCP 5683 and UDP/TCP 5684 should be open on your firewall.
May be caused by the SPI. For troubleshooting purposes you could try to disable just that if it allows you to. I have had similar issues with that in the past with SPI blocking UDP traffic. A firmware upgrade might fix it too if one is available for your modem.
Yep, changing the firewall strictness level has helped. Thanks!