This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C129EKCPDT: Encountering Error (-103) During HTTPS Post with Hardware Encryption

Part Number: TM4C129EKCPDT

Hi,

I would like to follow up on the E2E thread https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1236786/tm4c129ekcpdt-https-post-giving-a-error-400 , which was initiated by one of my colleagues.

Currently, I am encountering an error (-103) when I use hardware encryption, while software encryption is executing successfully. I am attempting to post to webhook.site:443. Please assist me in resolving this issue.

  • Hi,

      I'm not sure what caused the -103 error. I search online and find the below description. 

    https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103

    The HTTP 103 Early Hints information response may be sent by a server while it is still preparing a response, with hints about the resources that the server is expecting the final response will link. This allows a browser to start preloading resources even before the server has prepared and sent that final response.

    The early hint response is primarily intended for use with the Link header, which indicates the resources to be loaded. It may also contain a Content-Security-Policy header that is enforced while processing the early hint.

    I wonder if your wolfSSL library is built to utilize the hardware AES hardware accelerator. 

    If you have built the wolfSSL library then you should see the ${WOLFSSL_DIR}\tirtos\packages\ti\net\wolfssl\lib\wolfssl_tm4c_hw.aem4f library that is built for using the hardware accelerator. In your linker command file, you need to specify the path to this wolfssl_tm4c_hw.aem4f library, not the wolfssl.aem4f library. 

    If you have done all that is mentioned and still face the same issue then I really don't know what is wrong. I don't have expertise in this area. You might need to contact wolfSSL vendor for support. I will suggest you also look at the AES/DES module registers and see if they have been enabled and if these modules are being activated and doing some operations. You can check them in the register browser windows. You can also debug the code the normal manner by using breakpoints and single step the code to find out what caused the 103 to generate.  

  • Hi Charles,

    I have already linked the 'wolfssl_tm4c_hw.aem4f' library, but it is showing an error (-103). With the 'wolfssl.aem4f' library, I can successfully connect to the server using software encryption.

    I have a doubt: is there anywhere I need to enable the AES hardware accelerator?

  • Hi,

    I have a doubt: is there anywhere I need to enable the AES hardware accelerator?

      This is why in my last reply, I suggested you to look at the AES/DES hardware accelerator registers and see if they have been enabled and initialized to perform any operations. This will be part of the debugging process. 

  • Hi  Charles,

    Good day.

    Sorry for the late response. I inquired with the wolfSSL team regarding the situation, but the state remains unchanged. I suspect that the hardware accelerator may not be configured or enabled.

  • Hi,

      Can you observe the registers for AES and DES to see if they are enabled and initialized. 

      

  • Hi Charles,

    It shows 'unable to read.

  • Hi Sony,

      Apparently, the wolfSSL library did not enable AES/DES for some reason. I suggest you go back and check how you build the wolfSSL library with hardware accelerator support. 

      Just to be sure, please go to 0x44036000 on the memory browser window. Do you see any initialization of any registers? Below is an example screenshot when running a simple TivaWare AES example. 

  • Hi Charles,

    While looking at the location you mentioned, no initialization has occurred.

    The settings I configured for the wolfSSL library are as follows,

      

  • Hi,

      I wonder if you have predefined WOLFSSL_TIRTOS and the corresponding MCU part number when you build your HTTPS project. 

    I want to also give you a heads-up. I will be vacation starting tomorrow for a week. Please expect delay in my response. 

  • Hi,

    These settings were suggested by wolfSSL support, and they are presented in the predefined section.

    But after defining these parameters, why is the hardware accelerator not enabled?

    Is it necessary to enable it separately?

  • Hi,

     Your screenshot looks fine with me but I don't know what is wrong; the -103 error message. Since I'm not an expert in the security layer, I will suggest you single step the TLS_Params_init() and TLS_create() functions and compare between using software encryption vs hardware encryption. Do you see where the difference might be? Another thing I can think of is to setup a watchpoint looking for any reads and writes to the AES and DES modules. This will tell us if the hardware accelerator is ever used by the WolfSSL library. AES module starts at 0x44036000 and DES module starts at 0x44038000. If the WolfSSL library or the HTTPS application needs to use the AES/DES, it must have tried to write to these these module registers in order to initialize the module. 

  • Hi,

    One more thing I would like to note is that, while debugging line by line, I have identified that the error occurs within a function in httpcli.c.
    /*
    * ======== sprsend ========
    * Constructs an HTTP Request line to send
    */
    static int sprsend(HTTPCli_Handle cli, const char * fmt, ...)
    {
    char sendbuf[SEND_BUFLEN];
    int len = 0;
    int ret;
    int sendbuflen = sizeof(sendbuf);
    va_list ap;

    if (!getCliState(cli, INPROGRESS_FLAG)) {
    va_start(ap, fmt);
    len = xvsnprintf(sendbuf, sendbuflen, fmt, ap);
    va_end(ap);
    }
    #ifdef NET_SLP
    else {
    memcpy(sendbuf, cli->buf, cli->buflen);
    len = cli->buflen;
    }
    #endif

    if (len > sendbuflen) {
    return (HTTPCli_ESENDBUFSMALL);
    }

    ret = Ssock_send(&(cli->ssock), sendbuf, len, 0);
    if (ret < 0) {
    cli->sockerr = ret;

    return (HTTPCli_ESENDFAIL);
    }

    #ifdef NET_SLP
    if (ret < len) {
    cli->buflen = len - ret;
    if (cli->buflen > HTTPCli_BUF_LEN) {
    return (HTTPCli_EINTERNALBUFSMALL);
    }

    memcpy(cli->buf, ((uint8_t *)sendbuf + ret), cli->buflen);
    return (HTTPCli_EINPROGRESS);
    }
    cli->buflen = 0;

    #endif

    return (ret);
    }

    The API 'Ssock_send(&(cli->ssock), sendbuf, len, 0)' is returning a value of (-308), which is leading to a return value of (-103).