sdk-6.0.1: The buggy ota_server implementation

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 implementation in ota_server_thread_main() for receiving packet data is buggy:

wiced_packet_get_data(temp_packet, 0, (uint8_t**)&request_string, &request_length, &available_data_length);

if ( request_length != available_data_length )

{                      

  result = WICED_ERROR;    

  wiced_packet_delete(temp_packet);

  goto disconnect;         

}                      

1. It does not check the return value of wiced_packet_get_data() call

2. The way to handle request_length != available_data_length is wrong.

   request_length != available_data_length does not means error but current code just delete the packet and disconnect the connection which is *wrong*.

So I'm not surprised that users will randomly hit disconnect error when upload data to the ota_server.

0 Likes
21 Replies
DaBa_2244756
Level 5
Level 5
25 likes received 10 likes received 10 likes given

Hi Axel,

If you remember its old problem.

Not possible use wiced_packet_get_data function correctly with multiple packet.

It seems to me, that same problem with tls, because this function used internally.

I rewrited in "classic multiple packet reading way" with lwip functios and then working Ok without tls.

Darius

0 Likes

Surely I can fix it for my own usage and patch the sdk.

The main reason I reproted it on the forum is I believe cypress can fix it and then everyone gets benefit.

Somehow, I feel cypress don't really care about it. 😞

That pushes every users to repeat similar work to fix the bugs of the sdk.

0 Likes

I tried reproducing this on a 4343W platform with FreeRTOS-LwIP. Was not able to. Tried sending larger binary files as well, but still went through. Is there a way to consistently reproduce this?

-atul

0 Likes

You don't need a consistent way to reproduce it.

It's simply wrong if you read how the wiced_packet_get_data() API work.

0 Likes

Well, the API doesn't have support for multiple packets. We're working on a fix for multiple packets on LwIP. So if you had a way to reproduce this, it would make it easier to debug and make sure the fix works. Help us help you

-atul

0 Likes

From my point of view, the API indeed support packets with multiple netbuf.

That is why it provide fragment_available_data_length and total_available_data_length.

It is *wrong* in  the usage of the API.

Heaving loading can make it easier to reproduce.

Note, it's not to help *me*.

It's to help cypress to deliver a stable sdk.

Some of the wrong usage of this api might be in your binary library.

0 Likes

Fragmented packets aren't supported yet. We can get the first fragment but there is no support to get the remaining. And to prevent us missing the next fragments, the error check was added if ( request_length != available_data_length ). This is until fragmented packet support is added. You are right in saying that OTA might fail in LwIP because of this, but we are working on it.

I tried heavy loading (I'm guessing you mean send large file), but wasn't able to recreate the issue.

-atul

0 Likes

atjo wrote:

Fragmented packets aren't supported yet. We can get the first fragment but there is no support to get the remaining. And to prevent us -

If you mean not supported, the sdk *must* ensure network stack won't send you a packet with multiple netbuf. However that is not ture in current situation. Because it's possible to hit such case and when it happen users got data lost.

This is called *bug*.

I just point out the problem and hope cypress can fix the sdk bug to make it better.

ps. if you have problem to hit such issue, you should consider work on some code

    to endless repeat test it automatically. AFAICT, it can happen.

0 Likes

Yes. this needs to be fixed. There's a fix in the works.

Thanks Darius. We're trying the same thing. Which router are you using?

-atul

0 Likes

We tested with Aruba high speed - model not remember.  Maybe ap 225. Price about 600$.

We get it from sellers for some days testing.

With Ubiquiti  not often.

BR

Darius

0 Likes

Hi Darius,

Which version of sdk were you using? I just realized that you mentioned you used an AP for OTA, which means you used the snip.ota2_example. But there is no support for FreeRTOS-LwIP.

Thanks,

Atul

0 Likes

atjo wrote:

Hi Darius,

Which version of sdk were you using? I just realized that you mentioned you used an AP for OTA, which means you used the snip.ota2_example. But there is no support for FreeRTOS-LwIP.

Thanks,

Atul

This is probably off topic, but...

You said snip.ota2_example is not supported by FreeRTOS-LwIP.

Do you ever think what is the reason that it cannot work by FreeRTOS-LwIP build?

In the old days, the issue is because FreeRTOS build does not implement wiced_rtos_*_event_flags APIs.

However, these APIs are implementated in current SDK now.

I don't see any reason why snip.ota2_example cannot work for FreeRTOS-LwIP build.

Maybe you can try it.

0 Likes

axel.lin_1746341 wrote:

atjo wrote:

Hi Darius,

Which version of sdk were you using? I just realized that you mentioned you used an AP for OTA, which means you used the snip.ota2_example. But there is no support for FreeRTOS-LwIP.

Thanks,

Atul

This is probably off topic, but...

You said snip.ota2_example is not supported by FreeRTOS-LwIP.

Do you ever think what is the reason that it cannot work by FreeRTOS-LwIP build?

In the old days, the issue is because FreeRTOS build does not implement wiced_rtos_*_event_flags APIs.

However, these APIs are implementated in current SDK now.

I don't see any reason why snip.ota2_example cannot work for FreeRTOS-LwIP build.

Maybe you can try it.

atjo

I try to figure out why you think FreeRTOS-LwIP build cannot not support ota2_example.

How is your comment about my reply above? Did you try it?

0 Likes

Hi Atul

I used  3.7.3  ... 3.7.7  with freertos-lwip.  Sdk 4 was not supported freertos.

We not using wiced_packet_get_data function which cant work correctly with multipacket buffers.

BR.

Darius

0 Likes

Hi Atul

Her more information. I was reported at 2016.

community.cypress.com/message/29098#29098

I try use wiced_packet_get_data in different ways to avoid multipackets problem, but without success.  So I used classic lwip way to read multipacket frame. https we used small packet communication to avoid multipackets problem.

Darius

0 Likes

Hi Darius,

Can you try with 6.1? Also the make target you used. I'm confused when you say you used AP for ota.fr app. Are you building this?

snip.ota_fr-FreeRTOS-LwIP-BCM943438-SDIO-debug download run VERBOSE=1 JTAG=atmel

Regards,

Atul

0 Likes

Hi Atul,

>>>Can you try with 6.1? Also the make target you used. I'm confused when you say you used AP for ota.fr app.

I am sorry, but currently I cant do any real test, because I working with other project and don't have any test or demo board.

>>Are you building this?

>>snip.ota_fr-FreeRTOS-LwIP-BCM943438-SDIO-debug download run VERBOSE=1 JTAG=atmel

Yes I building this, because BCM943438 was custom platform. 

I compiled on wiced 6.1 this configuration.  But can't test on real demo board.

snip.ota_fr-BCM943362WCD4-FreeRTOS-LwIP-SDIO  VERBOSE=1

BR.

Darius

0 Likes

atjo wrote:

Yes. this needs to be fixed. There's a fix in the works.

atjo

The fix in sdk-6.1 is wrong so all the applications using asynchronous tcp callbacks

in FreeRTOS+LwIP build is buggy now.

1. Is the buggy ota issue fixed?

2. please start a new thread for asynchronous tcp callbacks

0 Likes

atjo wrote:

1. Is the buggy ota issue fixed?

2. please start a new thread for asynchronous tcp callbacks

I lost the enthusiasm to help improving your sdk.

So I'll stop bothering your and fix it by myself.

0 Likes

Hi atul,

>>I tried heavy loading (I'm guessing you mean send large file), but wasn't able to recreate the issue.

I reproduced it always with hight speed wifi router and file about 1Mbyte.  With low speed router it occurs, but not often.

BR

Darius

0 Likes