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]

Thanks! We'll look into it.

[Greg-DB]

@sundares80 I had the team look at this, but unfortunately, this dump appears to only contain the WiFi frames. Can you instead share a dump with the actual data (TCP + TLS frames) so we can inspect that particular alert, like shown in the earlier screenshot? Thanks!

[Здравко]

@Greg-DB, Do you think they are so stupid not to understand what's on the screen and what they send (if they are, no any chance)? As I said, they just try push the case away, while demonstrating something is doing.

The only way is @sundares80  to reproduce it and send the results. One advice received there and ignored sound good though:

---

... you can change the target to a Dump HTTP server (google for it, e.g. see https://httpdump.app/) and  check the log there.

---

...despite of possible TLS issue cannot be reproduced in such a way, but may be confirmed at least if any at all or completely rejected.

@sundares80, Try do the same what your TI supported is doing (or is trying at least). Catch the packets flowing between Dropbox and your device while using Wireshark. To filter only packets needed, put in the filer something like ip.addr == 162.125.80.19. The IP address is from the screenshot (just for the example), but make sure it's the actual one at the time of meas.

Good luck.

[sundares80]

Hi Greg,

Below is the answer provided by TI

no. we can't. I was using an air sniffer log where the TLS content is encrypted. 

On the application side you can only publish the socket payload (i.e. if you print the data passed to sl_Send - it will include the HTTP content) but not the entire TCP/IP packets (i.e. it will be text file with http text and not a pcap file). I think one of our customers already provided this to them.

I'm quite sure they can capture the connection log on their server

As per my knowledge, the issue is not with the HTTP (curl request/response). Dropbox servers have some latency with the TLS handshake. Did you upgrade https certificates with different cipher suits?

Regards,

Sundar

[Greg-DB]

@sundares80 Unfortunately this isn't something I can just retrieve from logs on our side. If you don't have a sample showing the issue you can share, please share specific steps, e.g., using curl, to reproduce the issue so we can investigate it that way. Thanks!

[Здравко]

@Greg-DB, just a reminder on this topic.

In meantime, I reproduced the issues @sundares80 observes. Yes, despite they are minor deviations, but there are such that appear regularly (regular is maybe not the most correct). Most of the regular clients (including curl, web browsers, etc.) ignore such types of errors, but using diagnostic tools (openssl test suite, for instance) they can be seen. Wow, they appear pretty often - at least once per every 2~3 API calls (in my case). Some very sensitive client may confused (most probably that's why TI clients fail).

Interesting thing, that I noticed, is when higher level error appears (broken API call formatting and so on), encrypt errors are almost missing. For correct API calls, they are raining though. 🤷 I hope this can show some trace to possible reason.

Again minor (almost invisible) bugs, but existing! Just try inspect with openssl. They appear inconsistently, but often enough to reproduce.

[Greg-DB]

@Здравко Thanks for the note! I'll ask the team if they can look into it that way.

[Greg-DB]

@sundares80 We wanted to ask again, since it would be helpful to the team, if you could get and share an unencrypted dump (that is, without the WiFi encryption). The screenshot you shared on 4/24/2024 seems to be of the format we would want to see, but that's not what was shared in the dump you shared the next day (as that one included WiFi encryption). I understand you or your vendor may not want to do so because that would involve effectively sharing the WiFi password, so that could instead be saved and shared as a separate dump, e.g., using the "Export Packet Dissections" "As Plain Text" option, so as not to share the WiFi password.

[sundares80]

@Здравко Thank you so much for recreating the issue.

Greg-DB Please find my new packet capture in the google drive link. Please let me know if it works

https://drive.google.com/file/d/1v4dUI2lMIRJ-1Qg-u2Phl10IhSpVuCJr/view?usp=sharing

Regards,

Sundar

[Greg-DB]

@sundares80 Thank you! We'll look into it.