4 Replies Latest reply on Aug 7, 2019 7:46 PM by ChMa_3922746

    "ssl_receive_packet" in file "wiced_tls.c" hangs CPU (SDK 6.4 on CYW943907AEVAL1F)

    ChMa_3922746

      Here is a surprising finding:  With mutual TLS authentication enabled (i.e., certificate enabled on both Firefox client and WICED HTTPS server), the function ssl_receive_packet in the file wiced_tls.c has a propensity to hang the CPU unless I delay the function by 50ms if the len parameter is less than 5:

       

      static int ssl_receive_packet( void *ctx, unsigned char **buf, size_t len )

      {

          wiced_result_t result;

          wiced_tcp_socket_t* socket = ( wiced_tcp_socket_t* ) ctx;

          uint16_t available_data_length = 0;

          uint16_t length = 0;

       

          WPRINT_SECURITY_DEBUG (("TLS library asked for [%d] bytes \n", len ));

       

          // delay workaround to prevent from hanging the CPU

          if (len <= 5)

              device_wait_ms(50);

      ...

       

      It used to hang almost immediately without the delay, but it seems to last longer with the delay.  The reason I found that a delay improves things is that when I enabled the debug print statements, the problem became much less severe.  Example debug print output that seemed to help (log level 0):

       

      TLS library asked for [5] bytes

      Received new TCP packet with length [427]

      TLS library asked for [422] bytes

      Skip [5] no of bytes from TCP received packet with length : [427]

      check if multiple TLS records present in single TCP pkt

      TLS library asked for [5] bytes

      Skip [427] no of bytes from TCP received packet with length : [427]

      wiced_packet_get_data failed with result : [4]

      TLS library asked for [5] bytes

      Received new TCP packet with length [395]

       

      There must be a timing-related problem in the code.

       

      Perhaps the dev team investigated this function in the past in this regard?