5 Replies Latest reply on Dec 20, 2017 11:28 PM by AxLi_1746341

    sdk-6.0.0: The buggy ssl_receive_packet/eap_ssl_receive_packet return code

    AxLi_1746341

      The prototypes shows

      typedef int mbedtls_ssl_recv_t( void *ctx,

                                      unsigned char **buf,

                                      size_t len );

       

      * \return         The callback must return the number of bytes received,

      *                 or a non-zero error code.

      *                 If performing non-blocking I/O, \c MBEDTLS_ERR_SSL_WANT_READ

      *                 must be returned when the operation would block.

       

      However, take a look at ssl_receive_packet/eap_ssl_receive_packet functions:

      They return wiced_result_t which is obviously wrong.

      Both TLS_ERROR_OUT_OF_MEMORY and TLS_NO_DATA are positive values,

      so you cannot differentiate the error code at all.

       

      In additional, I'm confused about the return WICED_SUCCESS (0) code paths.

      I thought it should return the number of bytes received.

        • 1. Re: sdk-6.0.0: The buggy ssl_receive_packet/eap_ssl_receive_packet return code
          AxLi_1746341

          So I found WICED hack the code as :

           

          After ret = ssl->f_recv( ssl->p_bio, &ssl->in_hdr, len );

           

          #ifdef WICED_MBEDTLS

                      /* If receive callback returns SUCCESS meaning, We have received some number of bytes. If there is an error, return it to library/application */

                      if ( ret != 0)

                      {

                          return ret;

                      }

          #endif

           

          AFAICT, this is a messy and wrong way to hake mbed_tls.

           

          HINT: It's easy to have some f_recv() call miss such hack.

          • 2. Re: sdk-6.0.0: The buggy ssl_receive_packet/eap_ssl_receive_packet return code
            AxLi_1746341

            Just running httpbin_org snip, my debug code shows ssl_receive_packet() return error.

             

            ssl_receive_packet() fails because

            result = tls_host_get_packet_data( &workspace->tls_context->context, workspace->tls_context->context.received_packet, workspace->tls_context->context.received_packet_bytes_skipped, (uint8_t**) ( buf ), (uint16_t*) &length, &available_data_length );

            fails

             

            With ThreadX build, ssl_receive_packet() returns WICED_ERROR.

            With FreeRTOS build, ssl_receive_packet() returns WICED_CORRUPT_PACKET_BUFFER.

             

            www.httpbin.org is at 23.23.247.89␍␊

            Connecting to www.httpbin.org␍␊

            Connected␍␊

            ssl_receive_packet: ret=27

            Recieved response for request #1. Content received:␍␊

            ....

             

            The snip code works, but the ssl_receive_packet error looks suspect.

             

            GauravS_31

            • 3. Re: sdk-6.0.0: The buggy ssl_receive_packet/eap_ssl_receive_packet return code
              AxLi_1746341

              axel.lin_1746341 wrote:

               

              Just running httpbin_org snip, my debug code shows ssl_receive_packet() return error.

               

              ssl_receive_packet() fails because

              result = tls_host_get_packet_data( &workspace->tls_context->context, workspace->tls_context->context.received_packet, workspace->tls_context->context.received_packet_bytes_skipped, (uint8_t**) ( buf ), (uint16_t*) &length, &available_data_length );

              fails

               

              With ThreadX build, ssl_receive_packet() returns WICED_ERROR.

              With FreeRTOS build, ssl_receive_packet() returns WICED_CORRUPT_PACKET_BUFFER.

               

              I figure out the returns WICED_CORRUPT_PACKET_BUFFER in FreeRTOS build is

              because the code in ssl_receive_packet try to read the end of a packet. (offset == packet_data_len)

              e.g.I got below debug message:

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

              1 of 1 people found this helpful
              • 4. Re: sdk-6.0.0: The buggy ssl_receive_packet/eap_ssl_receive_packet return code
                AxLi_1746341

                While testing sending https request to requestb.in, I hit another bug in the BESL.

                Sometimes, The wiced_packet_set_data_start can fail because the offset

                "(uint8_t*) packet->ptr->payload - data_start" is larger than packet->ptr->len.

                 

                Here is an example:

                In wiced_tls_receive_packet:

                        tls_host_set_packet_start: the packet->ptr->payload is 0x20010548

                        data: 0x2000fedd

                        end_of_data: 0x200100c4

                 

                "packet->ptr->payload - data" is bigger than p->len

                The "end_of_data - data" is quite small.

                 

                In additional, the wiced_packet_set_data_start() can fail.

                Current code does not check the return value at all.

                e.g. tls_host_set_packet_start() always return TLS_SUCCESS which is wrong.

                The result could be memory corruption due to access invalid memory address.

                 

                This time I test on sdk-6.0.1 with freeRTOS build.

                1 of 1 people found this helpful
                • 5. Re: sdk-6.0.0: The buggy ssl_receive_packet/eap_ssl_receive_packet return code
                  AxLi_1746341

                  axel.lin_1746341 wrote:

                   

                  While testing sending https request to requestb.in, I hit another bug in the BESL.

                  Sometimes, The wiced_packet_set_data_start can fail because the offset

                  "(uint8_t*) packet->ptr->payload - data_start" is larger than packet->ptr->len.

                   

                  I see the problem now.

                  Everytime I hit the problem sending https request, I found it's the case

                  with wiced_packet_get_data() call that fragment_available_data_length != total_available_data_length.

                   

                  To receive all data from a packet, the caller needs not only check the result (WICED_SUCCESS) but

                  also needs to check if fragment_available_data_length==total_available_data_length or not.

                  It may need to call wiced_packet_get_data() more than once to get all data in one packet.

                  The usage of wiced_packet_get_data() call is wrong in most of the sdk code.

                  The snip code works just because good luck where a single wiced_packet_get_data() call gets all data.

                   

                  GauravS_31

                  I think you should inform the RDto check this ASAP. (Also needs to check the binary library part).

                  This might be related to the PEAP/EAP-TLS failure because it's also used by eap_ssl_receive_packet().

                   

                  MichaelF_56

                  1 of 1 people found this helpful