- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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