Topic: wolfSSL-2.8.0 for embedded SSL on STM32F417 (FreeRTOS - Lwip).

Hello and Happy New Year!  big_smile

For my first post I will try to be clear. I've searched a lot the solution on this forum, but I found nothing.  sad

- The exercise is to install a webserver on a STM32 project. And this part works perfectly!

Now, I try to implemented a secure communication. => With wolfSLL 2.8.0

My problem is this:

1- Client/Server => Client on Visual studio/Server on STM32

Everything seems to work correctly.

http://w3.dvc-co.com/web/info/Capture1.PNG

http://w3.dvc-co.com/web/info/Capture2.PNG

2- Client/Server => Client Web browser/Server on STM32

This is where the problems begin:

http://w3.dvc-co.com/web/info/Capture3.PNG

More ... in the next post.

Share

Re: wolfSSL-2.8.0 for embedded SSL on STM32F417 (FreeRTOS - Lwip).

In Wireshark, I see a problem.

http://w3.dvc-co.com/web/info/Capture4.PNG

And the error is here:

        case SERVER_HELLO_DONE :
            if (!ssl->options.resuming) {
                while (ssl->options.clientState < CLIENT_FINISHED_COMPLETE)
                    if ( (ssl->error = ProcessReply(ssl)) < 0) {
                        WOLFSSL_ERROR(ssl->error);
                        return SSL_FATAL_ERROR;
                    }
            }

ssl->error = -208

Can you help me? I may be missing something.

I thank you in advance for your help.

Share

Re: wolfSSL-2.8.0 for embedded SSL on STM32F417 (FreeRTOS - Lwip).

Hi djconcept,

The -208 error is a SOCKET_ERROR_E, or "error state on socket".

We typically use the echoserver (./examples/echoserver/echoserver) to test against browsers, as it handles connections a little different. Browsers usually need to re-try the SSL handshake at least twice, as they need to ask the user to confirm connecting to an "unsecure" site (because our test certificates are self-signed).

It may be that your client (Chrome) is trying to do a second connection attempt, when your server has already shut down.  To see the difference, if you run our example server on your desktop machine (./examples/server/server), then connect through your browser:

https://127.0.0.1:11111

You'll see the inaccessible error from Chrome like you listed above.  If you then try with our echoserver example (./examples/echoserver/echoserver), you should see that it works like expected.

Best Regards,
Chris