OTA update fails in CC3200

[sundares80]

Hi All,

We are using the Dropbox API to do an OTA upgrade. We have a webclient application running on the TI microcontroller CC3200. We are using the Drop Box API from 2017 onwards, and it is working fine. When we tested the OTA functionality yesterday, it was unable to receive the CDN file URL.

It is able to receive the file information from Dropbox but is unable to get the temporary link from Dropbox.

Do you know what is causing this issue? Is there any recent API upgrade that has failed to respond?

Please help us to fix this issue ASAP.

TI CC3200 logs:

sl_extLib_OtaRun: call OtaClient_ConnectServer OTA server=api.dropbox.com
OtaClient_ConnectServer: http_connect_server api.dropbox.com
0 OTA run = 0
sl_extLib_OtaRun: OtaClient_UpdateCheck, vendorStr=Vid01_Pid00_Ver0302100000
OtaClient_UpdateCheck: call http_build_request /1/metadata/auto/
CdnDropbox_SendReqDir: uri=/2/files/list_folder
metadata file=/Vid01_Pid00_Ver0302100000/f80_sys_mcuimgA.bin, size=142888
sl_extLib_OtaRun: OtaClient_UpdateCheck, numUpdates=1
0 OTA run = 0
sl_extLib_OtaRun: OtaClient_GetNextUpdate: file=/Vid01_Pid00_Ver0302100000/f80_sys_mcuimgA.bin, size=142888
OtaClient_ResourceMetadata: call http_build_request /1/media/auto
OtaClient_ResourceMetadata: file flags=80,metadata flags=80
CdnDropbox_SendReqFileUrl: uri=/2/files/get_temporary_link
0 OTA run = 0
sl_extLib_OtaRun: ResourceMetadata CDN file URL = f=
CdnClient_ConnectByUrl: ERROR, http_extract_domain_by_url, status=-1
sl_extLib_OtaRun ERROR: Failed on CdnClient_ConnectByUrl
0 OTA run = -6
OTA run = -6
OTA: Error with OTA server

Regards,

Sundar

[Greg-DB]

This output doesn't show the actual request/response for the API call. Are you able to retrieve the actual request and response showing the issue?

I'm not aware of a bug on the Dropbox servers that should be causing this. This sounds like this earlier report we received, but we weren't able to identify or reproduce the actual issue there.

[sundares80]

Hi Greg,

Thank you for reply.  We have many WIFI module chipsets like CC3200, CC3220, CC3235. All of them failed to receive the data from Dropbox. Texas instruments claims that the chipset could not able to send and receive data using their low level HTTP Client library.  Did you modified anything related API (TCP/IP layer changes) for last 2 to 3 months? It was worked for past 5 several years. It is now impacting our business and our clients. Could you please help us to resolve the issue.

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1337191/cc3200-ota-e...

Regards,

Sundar

[Greg-DB]

While there may have been updates to the Dropbox servers in this time, I'm not aware of anything that should be causing the servers to incorrectly fail on API calls like this.

If there seems to be an issue with the Dropbox API, please share the actual raw HTTP request and response (showing both the headers and bodies for both, but redact the access token) so we can reproduce the issue and look into it. Thanks!

[sundares80]

Hi Greg,

Thank you so much for the reply. TI is saying it is a TLS handshake issue. request/response structure looks good. But there is a performance related issue.

Please refer to the link in the in the attached thread.

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1337191/cc3200-ota-e...

Here is the answer from TI: 

It looks like following the first request+response (list folder) the Dropbox server sends a TLS alert from some reason (downgrading the connection to unsecure).
I don't understand the reason (maybe the Dropbox contact can explain this).
If you delay the 2nd request (get-temporary-link) by few seconds (e.g "sleep(5)") the TLS connection will be reestablished and OTA will work.

Regards,

Sundar

[Здравко]

Hi @sundares80,

It's good idea to ask the TI support how exactly they reach to that conclusion. More steps to reproduce that inability to execute 2 consecutive requests would be useful - i.e. exactly what's the request content and so on. I just executed 2 requests - 1 list and 1 get temporary link - sticked together. Using either single stream or 2 independent streams in borders of single connection (i.e. HTTP1 or HTTP2) work fluently. Even more, some time ago I tested 2 overlapped requests in borders of single connection (sending second request before wait for the first to end) - again flawless. I posted Python sample code here, but likely removed already.

In short - you don't need to wait between requests and their explanation sounds like they're trying to rip you off. 🤷

Ask them for a way to reproduce for whatever they stated or will state. For example - curl. This command can reproduce almost everything. Can they offer a way for reproduction of their observations using 'curl'? The same using any other popular tool or program code...

Good luck.

[Greg-DB]

@sundares80 I'm not aware of any TLS issues on the Dropbox API servers that should be causing this. We'd be happy to look into it, but we'd need some more specific information. As Здравко said, we'd need to know exactly how to reproduce the issue you're seeing, so please share the specific steps and code to reproduce it.

Also, the output you shared here seems to show some logging specific to the device platform you're using. Can you share any network logging showing the actual TLS issue you're referring to? For instance, a tcpdump showing the issue would be helpful.

[sundares80]

Hi Greg,

Thank you both of them for checking this.

Here is the packet capture I got from TI.

This is what I have (the data is encrypted under the TLS):

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1337191/cc3200-ota-e...

If the screenshot not clear, Please use the above link.

The Alert is in frame 55151

Please let me know if you have any fix for this.

Regards,

Sundar

[Greg-DB]

@sundares80 Thanks for sharing that screenshot. Can you share the whole dump though so we can inspect it? Thanks in advance!

[sundares80]

Hi Greg,

Please download the wireshark pcap file from below link.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/cc32xx_2D00_dropb...

Regards,

Sundar