- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Labels:
-
Over The Air Updates (OTA)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. Is the buggy ota issue fixed?
2. please start a new thread for asynchronous tcp callbacks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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