sdk-6.0.0: The buggy ssl_receive_packet/eap_ssl_receive_packet return code

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

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.

0 Likes
5 Replies
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

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.

0 Likes

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.

grsr

0 Likes

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]

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.

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.

grsr

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().

mifo