OTA update fails in CC3200

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

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-error--6-for-dropbox/5162901#5162901

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

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.

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.

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-error--6-for-dropbox/5160405#5160405

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

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!

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-error--6-for-dropbox/5149726#5149726

Regards,

Sundar

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.