Wifi connecting, but connecting to cloud does not succeed

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.

Thank You, Mario

1 Like

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!?

Hi @mariog,

Fast flashing cyan on your core indicates that the secure handshake is failing on your core. This can also be represented by flashing orange: http://docs.spark.io/#/connect/troubleshooting-by-color-flashing-orange-red-yellow .

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.

Thanks!
David

Ok, finally made it through the instructions.

  1. it was really hard to get the dfu-util etc for windows
  2. my windows driver got a screwed up after doing the dfu-util. I had to reinstall the spark core drivers.
  3. key gen worked fine.
  4. 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

I must have good timing, just caught your post! :smile:

1.) dfu-util link for others for windows is here: http://dfu-util.gnumonks.org/releases/dfu-util-0.7-binaries.7z (in the win32 folder)
2.) – yeah, installing the drivers on windows isn’t great yet, working on it!

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.

The der file is just a binary format of a public or private key, but you can grab that file here:
https://s3.amazonaws.com/spark-website/cloud_public.der

Looking forward to adding your new public key, Thanks!
David

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!

Thanks
Mario

I have emailled my new public key, but no news yet, and no success connecting yet.

As added info to describe my problem,
I get the following TCP packet exchange (same as I have been having since the start):

  1. core > cloud: syn
  2. cloud > core: syn ack
  3. core > cloud: syn
  4. cloud > core: psh, ack (malformed packet in many cases)
  5. core > cloud: ack
  6. core > cloud: CoAP Reset
  7. cloud > core: ack
  8. cloud > core: CoAP (seems to be non-parseable CoAP)
  9. core > cloud: ack
    15 seconds later…
  10. cloud > core: TCP Keep-Alive
  11. core > cloud: TCP Keep-Alive Ack
    15 seconds later…
  12. cloud > core: FIN, ACK
  13. 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 ?

Mario

Hi @mariog,

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.

Thanks!
David

I just tried again a few times, and I get exactly the same result.

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.

Hi @mariog,

Factory reset won’t touch the keys stored on external flash. Don’t worry, we’ll get you up and running! :smile:

Thanks,
David

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)?

Hi @mariog,

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. :slight_smile:

Thanks!
David

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.

Or I can just wait.

I am still very optimistic.

Mario

Hi @mariog,

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.

Thanks!
David

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.