-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Red Blinking Light O' Death #6
Comments
One thing that helped me was setting the timeout to something 8 seconds. On Mon, Dec 7, 2015, 08:36 James K. [email protected] wrote:
|
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! |
Hi, @jhlink I'm still facing the issue. |
Ah, sorry. No, I haven't. This is still an ungoing issue. 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.
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. |
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. |
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: just to show you, if you get some ideas from the library. I think they use WolfSSL library. here's an example (it just too easy looking and maybe thats why it doesn't work with eg. 2048 RSAs:
|
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. 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. -Peter 2016-09-01 0:25 GMT+03:00 James K. [email protected]:
|
Anyone have an update on this? After 2 or 3 post calls I get the Red Blinking Light O' Death! :/ |
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
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. |
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...
Eventually I get a response with the following.
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.
The text was updated successfully, but these errors were encountered: