Red Blinking Light O' Death

The Red SOS appears!!

When I run the Glowfish - timeapi-test.ino file, initially the file runs fine, but eventually the particle dies and runs into Red SOS mode. I've been looking through Serial to see what the problem might be, and I noticed that when this series of lines occurs...

"HttpClient>    Done before full len\n0"

Eventually I get a response with the following.

Received: 0
FAIL: no HTTP Response
free memory: 36332

Right at this moment, the Photon proceeds to go into SOS, with I believe one blink right after the trio of red light blinking patterns. (#1 -> Hard Fault. Here's the list with the full blinking list of errors.)
https://docs.particle.io/guide/getting-started/modes/photon/#wi-fi-module-not-connected

I think somewhere a Particle engineer said that the HTTP call timeout was four seconds, which isn't enough time for the Particle to get a response, apparently.

I'm wondering why we're running into a hard fault at all if we're just waiting for a response.
--> Will continue to look into this.

One thing that helped me was setting the timeout to something 8 seconds.
For some reason TCP packets take a long time to get to the photon
(sometimes).

On Mon, Dec 7, 2015, 08:36 James K. notifications@github.com wrote:

The Red SOS appears!!

When I run the Glowfish - timeapi-test.ino file, initially the file runs
fine, but eventually the particle dies and runs into Red SOS mode. I've
been looking through Serial to see what the problem might be, and I noticed
that when this series of lines occurs...

"HttpClient> Done before full len\n0"

Eventually I get a response with the following.

Received: 0
FAIL: no HTTP Response
free memory: 36332

Right at this moment, the Photon proceeds to go into SOS, with I believe
one blink right after the trio of red light blinking patterns. (#1
#1 -> Hard
Fault. Here's the list with the full blinking list of errors.)

https://docs.particle.io/guide/getting-started/modes/photon/#wi-fi-module-not-connected

I think somewhere a Particle engineer said that the HTTP call timeout was
four seconds, which isn't enough time for the Particle to get a response,
apparently.

I'm wondering why we're running into a hard fault at all if we're just
waiting for a response.
--> Will continue to look into this.

—
Reply to this email directly or view it on GitHub
#6.

Hmm.... That's an interesting solution...

I've been looking through the httpsclient-particle.cpp file, and there seems to be a larger underlying problem within httpsClientConnection. I haven't figured out pinpointed exactly what that might be due to the number of goto statements, but I'm hoping to get it worked out later tonight.

I'll increase the timeout and use it as a temporary solution, but I want to try and look for a more permanent solution. I'll post updates as soon as I can.

Changed the timeout for now. Let's see if this helps out a few people.

I'll give this a try tomorrow with my Photon!

@jhlink

Hi, @jhlink
Did you get the red blinking issue solved ?

I'm still facing the issue.

Ah, sorry. No, I haven't. This is still an ungoing issue.
I haven't been able to touch on this because of work.

I'm trying to rack my brains on how to resolve this, but at this point it's either reducing the code footprint and code refactoring everything or start again fresh with a different ssl/tls library.

The former isn't fun and will be very time consuming. The latter, not sure. I haven't gauged this yet. Getting a feel for things first before I decide on either.

I noticed, that if i have a particle.function that i call before the httpclienconnection is done the particle photon wont get a hard-fault i.e. red sos + 1 blink.

HttpClient>     Done before full len
0
Received: 0
Received something
httpsClientConnection Returned 1
Received: 0
Received something

Let me know if there is someting that should be tested. I'm in helping with the testing part since i'm a testengineer, and i really need a SSL library what ever the library is.

@pZq

It should still be a problem. And the reason for that is ungraceful recovery from a missing or severely delayed SSL packet. It will require a re-work.
@pZq Are you using the latest version? Can you tell me if this is happening every single time?

I left the post kind of short. I ment that if i call the function continuously without the httpsclient finishing i can continue calling the function that sends requests and it will always receive the response but as soon as i stop calling the function -> particle gets the hard fault.

I call the request function through particle cli or particle dev ide.

The particle will always get hard fault after second client. Call. -> after first response is done and before the next request.

:( Sounds like a problem I had. I tried changing the timeout times before the pushed change, but didn't amount to much.

Openpicus dev board had a quite simple SSL library. The problem with that device is, that it doesn't work against azure due to some certificate problems.

But in that library one basically just created a tcp socket to an ip or host address with port 443. with one call. The you applied SSL tunnel into the socket with one function and waited that certificate would be accepted. -> it didn't but that was a quite simple SSL library. Heres an example:
http://wiki.openpicus.com/index.php/Secure_Sockets_Layer_(SSL)

just to show you, if you get some ideas from the library. I think they use WolfSSL library.
https://github.com/wolfSSL/wolfssl

here's an example (it just too easy looking and maybe thats why it doesn't work with eg. 2048 RSAs:

Socket=TCPClientOpen ( dot.host.com, "443");
vTaskDelay(25);
flagTCP=TCPisConn(Socket);
flagTCPisCON=flagTCP;
if(flagTCPisCON==TRUE)
{
TCPSSLStart(Socket);
while(TCPSSLStatus(Socket) == 1); // wait for Certificate handshake (never got through this)

TCPWrite(Socket, "POST https://host.dot.com/oauth2/token HTTP/1.1\r\nHost: dot.host.com\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: %d\r\n\r\n%s", (int)strlen(RequestBody), RequestBody));

TCPClientClose ( Socket );
flagTCPisCON=FALSE;   
}

One observation is also, that if the enpoint address is "faulty" i.e. POST request is sent to wrong address, then there is not problem. Photon receives 404 error and you can send normally a new POST request. Works correctly as it should without the Red SOS but as soon as enpoint address is correct, there is panic ongoing.

Any update on this issue ?

Oh, whoops!

It's been a while since I've thought about this.
The library is a bit obfuscated for me to try and fix the underlying problem.

I looked into seeing if I could make a new library from scratch using mbedTLS, which was a bit easier in comparison, but still a daunting task nonetheless.

I've had to pin this as a result. I'll be back on this once I have a better understanding of how mbedTLS works as a whole, but my hopes was that a Rust platform for the Particle could be built in time before this. It'd be great to capitalize on Cargo to access a larger breadth of libraries.

In the meantime, Photon has a TCPClient function that does make HTTPS calls, albeit its rate limited by Particle.

Ok, no problem. Thanks for the status update.
SSL/TLS is at the edge of IoT and i bet someone comes out with a library
suiting better these "low" rate CPUs.

-Peter

2016-09-01 0:25 GMT+03:00 James K. notifications@github.com:

Oh, whoops!

It's been a while since I've thought about this.
The library is a bit obfuscated for me to try and fix the underlying
problem.

I looked into seeing if I could make a new library from scratch using
mbedTLS, which was a bit easier in comparison, but still a daunting task
nonetheless.

I've had to pin this as a result. I'll be back on this once I have a
better understanding of how mbedTLS works as a whole, but my hopes was that
a Rust platform for the Particle could be built in time before this. It'd
be great to capitalize on Cargo to access a larger breadth of libraries.

In the meantime, Photon has a TCPClient function that does make HTTPS
calls, albeit its rate limited by Particle.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGU2ifVnwkAuSxtvZte57INqsVHuHw1Iks5qlfFlgaJpZM4GwSEi
.

Anyone have an update on this? After 2 or 3 post calls I get the Red Blinking Light O' Death! :/

@jhlink

Hello @jhlink @jersey99 @pZq @dhhagan Do you have any updates on this issues. Now my RED LED issues still exists :-( and it looks like I can't send request successfully before the CRASH SIGNAL comes up, and the prompt msg given by debugger is

matrixSSLNewClientSession: -10
New Client Session Failed: Existing

And also, it looks like the server (api.glowfi.sh) in example code is down for some reason, I can't find it using nslookup as well....

Let me know if you have any suggestions.

Where should I look for the cause of the red blink of death? I know this thread is pretty old, so I assume this has been abandoned, but I'm hoping not.

Navigation Menu

Repository navigation

Red Blinking Light O' Death #6

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Red Blinking Light O' Death #6

Description

Activity

jersey99 commented on Dec 7, 2015

jhlink commented on Dec 8, 2015

jersey99 commented on Feb 19, 2016

jhlink commented on Feb 19, 2016

pZq commented on Apr 1, 2016

jhlink commented on Apr 1, 2016

pZq commented on Apr 1, 2016

jersey99 commented on Apr 1, 2016

pZq commented on Apr 1, 2016

jhlink commented on Apr 1, 2016

pZq commented on Apr 1, 2016

pZq commented on Apr 7, 2016

pZq commented on Aug 30, 2016

jhlink commented on Aug 31, 2016

pZq commented on Sep 1, 2016

dhhagan commented on Jan 1, 2017

chen-code1994 commented on Jan 27, 2017

brad-colbert commented on Jun 19, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions