• From: Texas
  • Registered: 2020-08-17
  • Posts: 63

Topic: How to find out why SERVER hung up on me

Hello,
I build WolfSSL and ran a windows client test, connected to an SSL port 443 server.  All good.

Next I try to connect to the same server, with the same source code from an ARM device running TI_RTOS.
It fails with a -308  (error state on socket)

Well, something somewhere is different between the two test apps.

I ran a WireShark on the server and can see that the server is disconnecting after the ClientHello.

I can also see that the windows build has 51 cipher suites in it's offering, which the ARM build only has 18.

How am I supposed to determine:
1. What the reason is the server is rejecting the client hello?
2. How/Where to add any needed missing cipher suites to the Wolf build?

-Scott
<Code shown is not to scale>

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 357

Re: How to find out why SERVER hung up on me

Hello Scotty

The wolfSSL configuration is used to enable / disable support for features (including cipher suites) of the library. In the Win VS build, the configuration is handled by this file:
https://github.com/wolfSSL/wolfssl/blob … settings.h

Are you using a user_settings.h for the embedded system?

When building for embedded devices the best way to configure the wolfSSL library is to create a header named `user_settings.h`. Then at the global level in your application define `WOLFSSL_USER_SETTINGS` (or `./configure --enable-usersettings`) so that when `<wolfssl/wolfcrypt/settings.h>` is included throughout the library the `user_settings.h` header is also pulled in. The application should include `<wolfssl/wolfcrypt/settings.h>`, BEFORE all other wolfSSL headers. A good example `user_settings.h` for getting started on an embedded project can be found in:
https://github.com/wolfSSL/wolfssl/blob … settings.h
That example is well commented and provides a good starting point for any embedded project, even non-ARM based ones!

embhorn's Website

Share

  • From: Texas
  • Registered: 2020-08-17
  • Posts: 63

Re: How to find out why SERVER hung up on me

1.  One hour of writing a reply DOWN THE DRAIN, because this didn't autosave...  Here I go again. (GRRRRR)
(1.a  IT DID IT AGAIN!  Lucky for me I'm smart enough to learn NOT to trust this site...  I copied it before I hit post and lost everything. )

2.  Why is this NOT sending me notifications that a reply was posted??

3.  On to the problem,
I am using TIROTS, so I defined it in the settings.h

I am NOT using any configure build tool.  (Most nothing works right in these environments anyway, and usually requires a bloat-load of other freeware tools installed to make the scripts work).

I brought in the source, and built it in a TI CCS project.

All I need to do is provide the definitions to include the cipher suites that allow this to connect as an SSL client to a server, typically an IIS server.  It works in the Windows build, but not in the ARM TIRTOS build.

So I am fumbling around in the dark of lacking doc trying to figure out how to enable the suites.  Probably need to enable most of them to accommodate a wide variety of potential servers that will have to be connected to.

And yet...
https://www.wolfssl.com/docs/frequently … r_wolfSSL?
Tells me to put all the settings in "user_settings.h" and define WOLFSSL_USER_SETTINGS in the APPLCATION...

If I DON"T define it in the library how does it get those #defines into the lib?  They are already defined in the application, aren't they needed?
And those settings...
Are they supposed to be mimicked between "settings.h" and "user_settings.h" ?  Because they are in both...

The examples in IDE/GCC-ARM/Headers/user_settings.h have #defines that are redundant to the ones in sections of "settings.h"  (TIRTOS, FREERTOS, ARDUINO, etc...)
If I #define one of those systems in "user_settings.h" should they be removed from "settings.h"?
What if they conflict?  What if I don't want one, but it's defined in the other??

Of course... Windows build doesn't have ANYTHING from the "settings.h"  And gets everything from it's "user_settings.h".

I have already created a SSL Server in this ARM TIRTOS environment and selected the limited suites using wolfSSL_CTX_set_cipher_list(...)  and that all works fine.  But now I need a client.  And something in the ARM build isn't working.

(What fun...  retyping this all over again)

-Scott

-Scott
<Code shown is not to scale>

Share

  • From: Mobile, AL
  • Registered: 2013-12-11
  • Posts: 357

Re: How to find out why SERVER hung up on me

Hi Scott,

From the webpage you linked...

define the preprocessor macro “WOLFSSL_USER_SETTINGS” in your project

So in the project file that builds the wolfSSL library code, you should add a preprocessor macro for WOLFSSL_USER_SETTINGS. I clarify because you stated

define WOLFSSL_USER_SETTINGS in the APPLCATION...

The settings.h header will include user_settings.h, and those values will override anything in settings.h.

embhorn's Website

Share

  • From: Texas
  • Registered: 2020-08-17
  • Posts: 63

Re: How to find out why SERVER hung up on me

Hi...

"Project" is not clear.  The library is a project.  It's your project, as I didn't write it.
My application is a project.  I assume when your instructions write "your project", it means mine.

So I copied a bunch of the setting that were in the windows user_settings.h to the one in the ARM user_settings.h, and defined WOLFSSL_USER_SETTINGS in BOTH my app, and the library.

Well, that didn't work.  It used to disconnect due to the server hanging up on the client hello...

Now it craters hard on SSL_connect(...) in the following code.

   m_socket = ConnectToHost(m_host,m_port);
    if (m_socket == (int) INVALID_SOCKET) {
        return false;
    }
    if (m_useSsl == 0) {
        return true;
    }
    m_ssl = SSL_new(m_ctx);

    UARTprintf("Setting the socket FD %x to the SSL\n", m_socket);
    result = SSL_set_fd(m_ssl,m_socket);
    if (result < 0) {
        UARTprintf("Failed to set the socket: %d\n", result);
        return false;
    }
    UARTprintf("Triggering a SSL handshake %x\n", m_socket);
    result = SSL_connect(m_ssl);
    if (result <= 0) {        //  BAD_FUNC_ARG
        UARTprintf("Failed to negotiate an SSL connection: %d\n", SSL_get_error(m_ssl,0));
        return false;
    }
    UARTprintf("Verifying the certificate\n");
    success = VerifyCertificate();

It does NOT crater, and works fine for ALL the communication when not using SSL.

Nothing I (dis) like better than stepping through other peoples code when I know nothing about it, and can't find any doc on the dozens and dozens of #defines that control how it's built...

Scott

-Scott
<Code shown is not to scale>

Share