We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
OTA update fails in CC3200
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 wor...
Greg-DB
Dropbox Staff
Dropbox StaffThis 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.
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.
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!
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.
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.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
