I have managed to get Wifi going (via connecting by USB).
The core is on my local network. I can see it took an address on my DHCP server (embedded in the NAT/router).
I can even ping it from another machine on the local network!
But the core does not connect to the Cloud. I get the fast flashing cyan for ever.
So, I took Wireshark to my NAT/router WAN port and I see that the core is exchanging some packets with 54.208.229.4:5683 (as I believe it should). It seems to use the Constrained Application Protocol.
Typically after the first syn/ack syn/ack exchange the cloud send the first CoAP packet, but this packet is almost always a Malformed Packet.
Multiple resets of the core give mostly the same results each time (although sometimes, nothing is sent to the cloud, and on rare occasions, the malformed packet is the 2nd, 3rd or 4th one).
Any solution ideas, or future debugging ideas?
Itās such a promising board, I am looking forward to getting it working.
Update: after restarting it for the millionth time (and off course right after my post), I get a different error - no packet errors. Instead I get from the Cloud (as seen in Wireshark):
āConstrained Application Protocol, Reset, 5.05 Proxying Not Supported, TID:24199ā
So for once, I seem to get through, but actually rejected!?
Fast flashing cyan on your core indicates that the secure handshake is failing on your core. This can also be represented by flashing orange: Particle Welcome to the Particle docs .
Can you try these steps and email us your new core public key / id at hello@spark.io ?
edit: I would say that the 'malformed packet' stuff is probably a red herring at this point, we're sending coap, but the handshake itself isn't coap, and the messages after the handshake are encrypted.
it was really hard to get the dfu-util etc for windows
my windows driver got a screwed up after doing the dfu-util. I had to reinstall the spark core drivers.
key gen worked fine.
key upload seemed to work fine,
a) doing the backup gave weird results - it generated a 2M file (not sure that is correct).
b) i did not upload a new cloud cer, as the file I got was of type .cer, not .der - so was not sure I could trust it.
So I am emailing you the public key and id. I assume you need to get this into the cloud before I can try connecting again.
By the way, thanks for your initial quick response.
Mario
4.a.) dfu-util will assume you want everything when you āuploadā from your flash to your computer. so you can append a size with something like: ādfu-util -d 1d50:607f ā¦ -s address:bytes -U destinationā ā Thisāll be wrapped in the command line tool.
Hi,
Email with my public key was sent
Thanks for the link, but I found one somewhere and it all more or less worked.
As for the could key, for an odd reason, that link does nothing in Firefox, and downloads a .cer file in IE!?
So impatiently waiting for my key to be put up on the cloud so that I can try connecting again - got all my fingers crossed!
core > cloud: ACK
then nothing, ever, until I reset.
The above looks normal, except I get a feeling that after the cloud sends packet 8, it is expecting and waiting for my core to respond with something, and since it does not it terminates the connection? Is that what is happening? If so, why is my core not responding ?
The server has sent your core a packet encrypted with what it thinks is your coreās public key. Since your core has a different key, it canāt decrypt the message, and the handshake fails. I added the public key you sent to our database, so hopefully that will help things go through normally.
Even with my new keys (second attempt), and loading in the cloud public key, I am still getting exactly the same behavior as above! The only difference is I now see it flash red (on occasion only) - had never seen that before. But even in those cases the packet exchange appears to be the same.
I have done a hard reset quite a few times, still the same.
Question:
If I reset to factory, does that scrap the new keys I just put in?
I just cant believe this beautiful board is not working for me.
I did a factory reset to try in on another wifi network.
Still can use the android or ios apps to configure.
After configuring over USB, I still get all the way to fast flashing cyan only - ie. no cloud connection.
Is there a way to run this without encryption so that we can actually check what is going on in the handshake with the cloud?
Hi @mariog - unfortunately thereās no way to run it without encryption. The fact that, after all that, youāre still not getting connected makes it seem like something tricky might be going on.
Are there any firewall/captive portal/other trickery going on on your Wi-Fi network? Iāve seen a āfast flashā issue where the Core gets intercepted by a captive portal, and attempts to do a handshake with whomever has intercepted the signal, and gets stuck in the handshake forever. Anything about your network that might incur something that looks like a man in the middle attack (what the secure handshake is designed to protect against)?
Your core still has bad keys, even though we flashed some and you sent us a new key. I suspect there is a problem with how the key was written to your core, or how it was generated. Iām hoping the command line tool will help test and make sure thatās working for ya. Iāll send you an email about that later today.
I donāt think so. I have a standard wifi home access point (doing nat off course). I tried two, and same problem.
I guess I donāt understand the sequence in the handshake, and that is why I was wondering whether there was a āno encryptionā mode.
I will wait for Daveās command line tool (after I try to re-upload my keys again). He seems to think my keys are still bad (I think he is seeing that in your logsā¦).
Ok, Dave. I will wait for your tool.
Either my generation failed, or my loading the keys failā¦ (I hope it is not something else messed up in the firmware - it is strange that I always have to use USB to configure the wifi).
If you happen to have a working key pair, I am willing to try loading them to see if that would work - if it does, it means my key generation is wrong.
Happy to give a quick overview of the secure handshake:
Server -> Sends a random Nonce
Core -> sends back its unique id, encrypted with the serverās public key, and the nonce
Server -> generates a secure AES session key, signs it, and encrypts it with the coreās public key
Core -> starts using the new session key, and sends back hello
Server -> acknowledges the hello with its own hello.
Core and Server go about their business, and bi-directionally rotate the IV on the AES session after every message.
I can tell those keys on the Core are bad because in the server logs the server gets the core id, but your Core fails the handshake and doesnāt respond when the server sends it a message using that public key.
Im getting slow cyan flash, but no uploads.
error is sparkio "the server has failed to process the upload in time"
After a factory reset, still get the same issue.
I have done no firmware upgrades to the spark, but not sure if its needed or how to do it.
