1 of 1 people found this helpful
Can you please let me know the OS you are using? Is the issue seen during handshake or application data exchange?
It will be helpful if you can list out the steps to reproduce the issue.
Thank you very much for your reply. I am using Firefox on Linux and connecting to an HTTPS server running on the WICED device.
I can invoke the failure most easily by rapid-firing page reloads via Firefox to the HTTPS server with a certificate mismatch. If I keep it up, then eventually the CPU grinds to a halt and does not recover. Have more than one HTTPS client requesting pages provokes the problem even further and more quickly.
Attached is a Wireshark capture. The bottom-most RST is where the CPU is no longer responsive. It seems that the CPU gets progressively bogged down by the page reloads.
My suspicion is around TLS due to the fact that adding the delay seems to help. It could be that mbedTLS doesn't do well in the face of a barrage of incoming packets. It would be Ok if it failed gracefully in a way that didn't freeze or force a reboot, however (in a way that could be more easily recovered).
I look forward to any advice or input you might have. Thank you!
server_failure.png 230.6 K
I tried to replicate the problem with the same setup.
HTTPS server in WICED device CYW943907AEVAL1F with ThreadX/Netx-Duo stack and Firefox runnign on Linux laptop as client. I tried to reload the server 15-20 times from the firefox browser and the system is reponding to all requests.
Thank you very much for trying to replicate the problem. I think it might take more than 15-20 times.. kind of like a DOS attack If you can get more than one client going at the same time, you will probably see the failure. I know it isn't easy to replicate, but once you do, you will see what I mean...