The core resets OK and configuring the network via serial port appears to work, however it then steps into this cycle of ~10s in each colour. This is not described in the troubleshooting page.
Please advise.
The core resets OK and configuring the network via serial port appears to work, however it then steps into this cycle of ~10s in each colour. This is not described in the troubleshooting page.
Please advise.
That sounds like bad keys which is documented in the troubleshooting page you mentioned.
http://docs.spark.io/troubleshooting/#troubleshoot-by-color-flashing-orange-red-yellow
You can fix this using spark keys doctor core_id
in DFU mode to repair the keys via Spark-cli
Do you mean Flashing orange (red/yellow)? This is not what Iām seeing.
(Am happy to try the instructions, however I need to upgrade dfu-util to do so, and canāt do that today.)
It sounds most likely to be that case.
Is the dfu-util version 0.7 for you? Thatās sufficient for the spark core
The instructions require 0.7, I have 0.5 Will update soon and try again.
OK, have worked through the instructions, with no change. Please advise.
$ openssl genrsa -out core.pem 1024
Generating RSA private key, 1024 bit long modulus
.................++++++
..++++++
e is 65537 (0x10001)
$ openssl rsa -in core.pem -pubout -out core_public.pem
writing RSA key
$ openssl rsa -in core.pem -outform DER -out core_private.der
writing RSA key
$ sudo dfu-util-0.8-binaries/linux-i386/dfu-util -d 1d50:607f -a 1 -s 0x00002000:4096 -v -U old_core_private_key.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 1d50:607f
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "SPI Flash : SST25x"
Memory segment at 0x00000000 512 x 4096 = 2097152 (rew)
Poll timeout 50 ms
Poll timeout 0 ms
Upload [=========================] 100% 4096 bytes
Upload done.
$ ls -lrt
total 20
drwxr-xr-x 4 raz raz 4096 Sep 13 21:57 dfu-util-0.8-binaries
-rw------- 1 raz raz 887 Nov 17 20:51 core.pem
-rw------- 1 raz raz 272 Nov 17 20:51 core_public.pem
-rw------- 1 raz raz 608 Nov 17 20:51 core_private.der
-rw------- 1 root root 4096 Nov 17 20:53 old_core_private_key.der
$ sudo dfu-util-0.8-binaries/linux-i386/dfu-util -d 1d50:607f -a 1 -s 0x00002000 -v -D core_private.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
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:607f
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 1024
DfuSe interface name: "SPI Flash : SST25x"
Memory segment at 0x00000000 512 x 4096 = 2097152 (rew)
Downloading to address = 0x00002000, size = 608
Download [ ] 0% 0 bytes Poll timeout 20 ms
Poll timeout 0 ms
Download from image offset 00000000 to memory 00002000-0000225f, size 608
Poll timeout 30 ms
Poll timeout 0 ms
File downloaded successfully
$ wget https://s3.amazonaws.com/spark-website/cloud_public.der
--2014-11-17 20:55:53-- https://s3.amazonaws.com/spark-website/cloud_public.der
Resolving s3.amazonaws.com (s3.amazonaws.com)... 54.231.244.0
Connecting to s3.amazonaws.com (s3.amazonaws.com)|54.231.244.0|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 402 [application/x-x509-ca-cert]
Saving to: ācloud_public.derā
100%[===========================================================================================================>] 402 --.-K/s in 0s
2014-11-17 20:55:54 (1.18 MB/s) - ācloud_public.derā saved [402/402]
$ sudo dfu-util-0.8-binaries/linux-i386/dfu-util -d 1d50:607f -a 1 -s 0x00001000 -v -D cloud_public.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
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:607f
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 1024
DfuSe interface name: "SPI Flash : SST25x"
Memory segment at 0x00000000 512 x 4096 = 2097152 (rew)
Downloading to address = 0x00001000, size = 402
Download [ ] 0% 0 bytes Poll timeout 20 ms
Poll timeout 0 ms
Download from image offset 00000000 to memory 00001000-00001191, size 402
Poll timeout 30 ms
Poll timeout 0 ms
File downloaded successfully
$
Using this instruction spark keys doctor core_id
should resolve it.
Seems like you only updated the server public key but the yellow/red flash is actually a problem with the core key
I donāt understand, are you saying that ādfu-util-0.8-binaries/linux-i386/dfu-util -d 1d50:607f -a 1 -s 0x00002000 -v -D core_private.derā doesnāt update the core key?
Also, repeating, I donāt have the yellow/red flash symptom.
Maybe someone else has to jump in on comment on this. My best guess is core keys issue since your other cores connected fine.
The command "dfu-util-0.8-binaries/linux-i386/dfu-util -d 1d50:607f -a 1 -s 0x00002000 -v -D core_private.der"
only flashes the private key on the core FLASH but does not send the public key to the cloud.
Using spark keys doctor core_id
or spark keys send
will upload the copy of the public key belonging to the core to the cloud
OK, have used the āspark keys doctor core_idā command, it looks as though it may have failed to upload.
# ./node_modules/spark-cli/bin/spark.js keys doctor core_id
running dfu-util -l
FOUND DFU DEVICE 1d50:607f
running openssl genrsa -out core_id_new.pem 1024
running openssl rsa -in core_id_new.pem -pubout -out core_id_new.pub.pem
running openssl rsa -in core_id_new.pem -outform DER -out core_id_new.der
New Key Created!
running dfu-util -l
FOUND DFU DEVICE 1d50:607f
running dfu-util -l
FOUND DFU DEVICE 1d50:607f
running dfu-util -d 1d50:607f -a 1 -s 0x00002000:1024 -U pre_core_id_new.der
running openssl rsa -in pre_core_id_new.der -inform DER -pubout -out pre_core_id_new.pub.pem
Saved!
checking file core_id_new.der
spawning dfu-util -d 1d50:607f -a 1 -i 0 -s 0x00002000:leave -D core_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
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:607f
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 1024
DfuSe interface name: "SPI Flash : SST25x"
Downloading to address = 0x00002000, size = 608
Download [=========================] 100% 608 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Saved!
attempting to add a new public key for core core_id
submitPublicKey got error: Permission Denied
Okay! New keys in place, your core should restart.
#
Opps.
You actually need to use your core id. spark keys doctor XXXXXXXXXXXXXX
Placing the core in Listening mode and typing i
on the serial terminal @ 9600 will give you the core id!
Yup, realised that after I posted. It now appears to be working, many thanks!
(In fact 2 cores had the same symptom, both are now working.)
Hey All,
Glad you were able to resolve this, thanks!
Thanks,
David
I have this rapid flashing orange, red, cyan ā¦repeating. I figured it was a core keys problem because I have been moving the core from cloud to local and back.
Anyway, I tried the spark keys doctor (coreID). command and was a bit surprised to get the following (which I find intelligible):
I get something similar if I try to load the cloud_public.der file.
Can anyone help. Iām pretty sure itās not the dfu or SSL because I just successfully set up new keys on another core and then switched it back to the public cloud. It just seems to be this one.
Thanks,
R
Hi @rblott,
The CLI is trying to load ācloud_public.derā, which Iām guessing is not a private RSA key pair, but the server key, Iām guessing you want:
spark keys server cloud_public.de
It looks like earlier, the CLI was trying to convert the backup key it copied from your core into other formats, but it was corrupt. If you run:
spark keys load 53ff<fill in the rest here>_new.der
,
and then spark keys send 53ff<fill in the rest here> filename.pub.pem
you should be set.
Thanks,
David
Thanks, Dave. Tried the first command and got this (tried as you recommended, then with --force):
anyone have any idea what I need to do to restore order to this poor core?
Can you use spark keys doctor core_id
instead ?