cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

user_2177781
Valued Contributor

Hello,

I'm having issues with wiced_tcp_stream_read. I have an application which downloads a file from a server using wiced_tcp_stream_read, the implementation has been working up to and on WICED 5.1, after porting the application to WICED 5.2, I have been experiencing issues.

In general I have two issues.

First, on one of the my test connections, the wiced_tcp_stream_read fails and returns error. I have been tracking the reason for the error and is currently stuck at a wiced_packet_get_data call in wiced_tls.c (line 586).

Second, one other connections, I see corrupt data. Suddenly a single data block contains a series of random bytes, which is not a part of the downloaded data. I see this issue on three connections and the random data is added at different locations in the data depending on which connection I try to download the file on. I have not been able to look further into this issue, but for one off the connections I have found the location at where the data gets corrupted. Additional if I do a CRC on the downloaded data, it calculates different values each time, despite I'm downloading the same file.

Any other experiencing issues like this ?

Regards

René Josefsen

0 Likes
1 Solution
user_2177781
Valued Contributor

I have tested the file download on the connections which failed in different ways on WICED 5.2 and I have not noticed any issues on WICED 6.0. All connections can download and generates the same (and correct) CRC value for the download.

Regards

René Josefsen

View solution in original post

0 Likes
11 Replies
user_2177781
Valued Contributor

Having looked a bit further into the random bytes, I have noticed that in one of the connections 4 bytes is added while on another 6 bytes is added.

I‘m currently looking at the defragmentation buffer which seems to suddenly include some additional bytes, I'm still trying to figure out where the data comes from.

user_2177781
Valued Contributor

A bit more information.

It seems that I at some point in the download process get a "amount_to_copy" of 1388 bytes in tls_complete_record_defragmentation, which means that when calling tls_consume_received_packet_bytes the ssl->received_packet_length is 12.

Next time the ssl_receive_packet is running, the length value is set to 12 and it then only process 7 of these bytes, where I can see that in the other cases it processes 13, (there is a MIN function to determine this). I'm not sure this is relevant, but this is a difference I have spotted between a succesful data block and then one which has random data added in the beginning.

Regards

0 Likes
AxLi_1746341
Honored Contributor

renejos wrote:

A bit more information.

It seems that I at some point in the download process get a "amount_to_copy" of 1388 bytes in tls_complete_record_defragmentation, which means that when calling tls_consume_received_packet_bytes the ssl->received_packet_length is 12.

Next time the ssl_receive_packet is running, the length value is set to 12 and it then only process 7 of these bytes, where I can see that in the other cases it processes 13, (there is a MIN function to determine this). I'm not sure this is relevant, but this is a difference I have spotted between a succesful data block and then one which has random data added in the beginning.

Regards

grsr

0 Likes
user_2177781
Valued Contributor

It looks like the 6 additional bytes I see is the remaining part of the "header" which is not being processed because I get a block of only 12bytes.

It seems to fit that it should process 13, but only takes 7 and leaves 6 that it adds to the data.

Are the WICED development team able to test this claim?

Regards

0 Likes
user_2177781
Valued Contributor

I tried looking deeper into the other issue, where it at one of the connections would fail completely. It looked like it was due to a bad handling of the situation where only 5 bytes was received and modifying

if ( len > ( socket->tls_context->context.received_packet_length - socket->tls_context->context.received_packet_bytes_skipped ) )

to

if ( len >= ( socket->tls_context->context.received_packet_length - socket->tls_context->context.received_packet_bytes_skipped ) )

seems to fix the issue

Regards

René

GauravS_31
Moderator
Moderator

I will try to reproduce this issue in our WICED devices. It will be helpful if you could share a sample code containing this issue.

AxLi_1746341
Honored Contributor

René Josefsen wrote:

I tried looking deeper into the other issue, where it at one of the connections would fail completely. It looked like it was due to a bad handling of the situation where only 5 bytes was received and modifying

if ( len > ( socket->tls_context->context.received_packet_length - socket->tls_context->context.received_packet_bytes_skipped ) )

to

if ( len >= ( socket->tls_context->context.received_packet_length - socket->tls_context->context.received_packet_bytes_skipped ) )

seems to fix the issue

Regards

René

I don't quite understand your change here.

Any chance to share the testing code so others can easily test it?

0 Likes
user_2177781
Valued Contributor

I do not have any "sample" code, since it is my main application and I'm downloading a firmware update.

But it seems to be dependent on some network settings of the packet size etc., since I see different sizes of the received data depending on what connection I'm using. The problems seems to start when the TLS header is split across two data blocks, and depending on where the split happens it gives different issues.

I can try to find time to make a sample code that download some random file and verify that it also have the issue.

0 Likes
user_2177781
Valued Contributor

There might be some "sample" code in this thread which might be used to reproduce the issue.

Files of more than 200KB get corrupted when downloaded via https in WICED 5.2

The description seems to indicate it is the same issue.

Regards

- René Josefsen

GauravS_31
Moderator
Moderator

WICED SDK 6.0 contains improvements in TLS fragmentation/reassembly handling. Can you check if this issue is still seen in WICED 6.0?

0 Likes
user_2177781
Valued Contributor

I have tested the file download on the connections which failed in different ways on WICED 5.2 and I have not noticed any issues on WICED 6.0. All connections can download and generates the same (and correct) CRC value for the download.

Regards

René Josefsen

View solution in original post

0 Likes