Photon setup flashing cyan with a "quick red burst" (now orange burst) [Solved]

Yeah okay.

That worked, I was thinking “login to the photon - what?” at 2am …
Maybe I should have gone to bed,

Thanks for the help. :slight_smile: my photon works now :wink:
Steps I followed:
File to download: https://s3.amazonaws.com/spark-website/cloud_public.der

$ particle login
$ particle keys server <the cloud public.der file I downloaded>
$ particle keys new photon           // photon is just the name of the file that will be created. 
$ particle keys load <photon.der.>    // photon.der is located in the same folder as the file above
$ particle keys send #photon ID# <photon.pum.pem>     // photon.pum.pem is located in the same folder as the files above

Then restart the photon :slight_smile:

3 Likes

So I am having a similar issue with my Photon. I keep getting the two orange/red flashes which indicate an incorrect key. I followed the steps on this thread and those of other threads but still not luck. I ensured the OpenSSL PATH is correct and re-installed the particle CLI. The output from the CLI indicates a success every time I use the keys doctor or similar. To prove it is not my internet, I created a hotspot with my phone and there is still no change.

There is one weird thing though:

While troubleshooting this, I took an old Redbear duo laying around and powered it up. It immediately connected to the cloud and starting publishing data. I then went to download a new blank sketch to the Redbear Duo and it automatically performed a firmware update (OK, I haven’t used it in a while so the firmware is old). Anyway, after the update, I am getting the same red/orange flashes on the Duo that was just previously working on my WiFi.

Am I missing some sort of cloud side authentication here?

Thanks for the help

Can you place the Photon in safe mode and see if it connects?

no, cant get it into safe mode either.

I just loaded it with the Cloud Debug firmware that rickkas7 created. It appears as though I key handshake error.

0000009509:ERROR: int SparkProtocol::handshake() (108):Handshake: Unable to receive key -19
0000009510:WARN : void handle_cloud_connection(bool) (268):Cloud handshake failed, code=-19

I have attempted to fix/load the keys a few times, but that has not fixed it. I am going to try downgrading the firmware to see if that makes a difference. Also, I was reading somewhere that running the command consul in Administrator makes a difference. I have been using Powershell up until now, so maybe that makes a difference?

OK, so I downgraded the firmware and used the keys doctor in the windows command prompt with Admin rights (instead of Powershell…) and that seemed to fix the issue. Interesting how using Powershell can make a difference.

Anyway, thanks for the help :slight_smile:

Worked great, back to breathing cyan. This has happened twice now. Has happened after my battery died each time

Thanks all.

Strangely had quite a few customer devices do this in the last 2 months. edit: quantified number: ~5 over 3 months. I was replacing the entire electronics and now know its this key issue. Either way it mailing costs and customer time offline isn’t desirable.

Followed Sebtech’s steps from Aug 14, but I’ve updated it to be a copy / paste with a prompt for the photon ID. May be useful to put in the online docs.

note, Paste paragraphs of commands separately

cd /tmp;
curl -O https://s3.amazonaws.com/spark-website/cloud_public.der
particle login
# provide input

particle keys server ;#<the cloud public.der file I downloaded>

particle keys new photon ;#          // photon is just the name of the file that will be created. 

particle keys load photon.der;    # photon.der is located in the same folder as the file above

export PHOTONID=[your photon ID]

echo "Received ID: $PHOTONID";
particle keys send $PHOTONID photon.pub.pem;     # photon.pub.pem is located in the same folder as the files above

All, thinking more about it, I’m not sure if requiring the user / manufacturer (ie like me) to fix up server keys on devices is the best solution.

It’d be much more preferable if devices would gracefully fall back to a tunnel endpoint that didn’t have encryption. Then it could load the server keys and be back in the game.

Simple logic being:

  • It’s theoretically hard to corrupt a device’s keys, though a MITM attack could convince a device it had bad keys
  • Even if a device received new keys via a MITM service, does that really matter? They wouldn’t be able to access the associated webhooks etc with that account. The device itself could be compromised as new malicious firmware could be sent to it from the MITM server, but that seems far preferable to me than having units in the field being borked (god knows how/why? interrupted firmware update??).
  • It could also be an account setting whether this fallback to plaintext is permitted.

Thoughts, feelings, emotions?
@mdma @kennethlimcp @Moors7

1 Like

@mterrill, system firmware v0.7.0 includes a self-healing feature for damaged keys. The bigger question is why are the keys getting damaged in the first place. Are these battery powered devices?

1 Like

oh that’s great news!

Some of them may be battery (5v power bank) powered. Customers have the option to power them however they like via a PCB dc barrel plug.

1 Like

Do test out the pre-release and see if there are issues before using it for a wider roll out :slight_smile:

well guys, 0.7.0-rc.3 does not self heal the keys. I had to repeat the new keys process above.

edit: well, at least in this cyan blinking then rapid red flash situation.

Incidentally, a device changing its keys has an impact on my application. I use the device’s public key as a segment of a passphrase token to authenticate that a given user’s mobile phone has indeed seen and paired with a particle while it was in listening mode. If this key is updated then the app will stop working. I’m changing this approach to associating a paired device to an user’s facebook login in the next version of our app due next month, but I’m sure other folk may have latched onto the public key as an interesting token of proof.

It’d be good if the particle subscribe logs highlighted when a device had come online with a new device key, then backend systems could appropriately remove/update the stored key. I’d update the token, then prompt the user app to pair again if their auth failed.

FYI, we had a similar problem (quickly flashing cyan with intermittent red blast after battery died) which none of the particle keys server particle keys doctor <DeviceID> particle keys new photon etc solved. Kept running into ‘permission denied’.

The solution for us was to remove the device from our Product Device list, then do the particle keys doctor <DeviceID>

The particle device doctor when you skip the first few steps, it has a section Resetting server and device keys where it does these steps for you. With 15k views on this thread it would be nice to document the features of the device doctor. I’m cloud connected after a few hours of reading of what could have been a fast fix.

@makerken, yep, thats an interesting new one in the latest CLI. Looks like a rough but handy combination of a series of the various commands.
I’m guessing ‘particle keys doctor [id]’ is the actual batch command its calling.

One thing I’d love is for the particle commands to simply kick the device into DFU mode via the ‘stty -f /dev/cu.usbmodemfd3411 14400’ command if it doesn’t find it in DFU.
Seems sensible, the multi-step particle device doctor should be able to be headless after giving it some flag like --auto / --all

1 Like

I have the cyan flashing with intermittent red flash. This Photon was running on batteries, which died. I plugged in USB power and I have not been able to resurrect it.
particle device doctor fails, Looks like it can't find the photon, even though it just flashed it. I noticed my PC is a little slow at refreshing the USB devices status. Is the doctor rushing things?

>particle device doctor
The Device Doctor will put your device back into a healthy state
It will:
  - Upgrade system firmware
  - Flash the default Tinker app
  - Reset the device and server keys
  - Clear the Wi-Fi settings

The Doctor will operate on your Photon connected over USB
You'll be asked to put your device in DFU mode several times to reset different
settings.

Updating system firmware

Put the device in DFU mode
Tap RESET/RST while holding MODE/SETUP until the device blinks yellow.
? Select Continue when ready Continue

> Your device is ready for a system update.
> This process should take about 30 seconds. Here it goes!

! System firmware update successfully completed!

> Your device should now restart automatically.


Flashing the Device Doctor app

This app allows changing more settings on your device

Put the device in DFU mode
Tap RESET/RST while holding MODE/SETUP until the device blinks yellow.
? Select Continue when ready (Use arrow keys)
> Continue
  Skip step
  Exit

At this point the photon is breathing white. I set the photon in DFU mode gain and continue

? Select Continue when ready Continue

Flash success!
The Doctor didn't complete sucesfully. Could not find serial device. Ensure the
Device Doctor app was flashed
> Please visit our community forums for help with this error:
https://community.particle.io

It looked like the doctor app disable the wifi because the device is left breathing white.
Resetting the photon makes it go back to the cyan blink with red.

I have tried skipping the doctor app flash step and went on to selecting the internal antenna, then got to select dynamic IP. At this point I get this error:

Configure IP address

? Select how the device will be assigned an IP address Dynamic IP
The Doctor didn't complete sucesfully. "path" is not defined: undefined

Please visit our community forums for help with this error:

Does Windows not know where to look? What is it looking for?

Please help, I've been at this for 3 days without finding my way out.
Thanks,
Pescatore

Can you place the Photon in safe mode and get it to connect to the cloud successfully?

I tried that yesterday and it would not stay in safe mode. It would try to connect and then revert to the cyan blink, indicating bad keys.
After all the things I tried, including resetting the public key, now it gets stuck at the fast green blink. So it looks like it lost the wifi setup.
I used the android app to reset the wifi and the app crashes (Samsung S4).
Using the CLI particle setup wifi does not find the photon wifi.
I used a iPad and got an error saying it cannot configure the wifi credentials.
Can this still be a public key issue?

Thanks for the response.
Pescatore

Possible. You can use particle keys server to flash the Particle public key.