We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.

Forum Discussion

Ingi's avatar
Ingi
Helpful | Level 6
4 years ago

SW updates via OTA dropbox failes CC3200

Hi,

 

Last week, I think about thursday 21st of October OTA updates started to fail. They have been working for years. I have turned the OTA logs on from the application side and you can see these below. I have not made ane changes in the application SW, the OTA just stopped to work.


OTA ongoing
EXTLIB_OTA_GET_OPT_IS_PENDING_COMMIT? 0
Starting OTA
sl_extLib_OtaRun: call OtaClient_ConnectServer OTA server=api.dropbox.com
OtaClient_ConnectServer: http_connect_server api.dropbox.com
sl_extLib_OtaRun: OtaClient_UpdateCheck, vendorStr=ODSIF_WIFI_36_D
CdnDropbox_SendReqDir: uri=/2/files/list_folder
metadata file=/ODSIF_WIFI_36_D/f80_sys_mcuimgA.bin, size=151320
sl_extLib_OtaRun: OtaClient_UpdateCheck, numUpdates=1
sl_extLib_OtaRun: OtaClient_GetNextUpdate: file=/ODSIF_WIFI_36_D/f80_sys_mcuimgA.bin, size=151320
OtaClient_ResourceMetadata: file flags=80,metadata flags=80
CdnDropbox_SendReqFileUrl: uri=/2/files/get_temporary_link
sl_extLib_OtaRun: ResourceMetadata CDN file URL = https://uc4e6d0a156efefbb6017fce8317.dl.dropboxusercontent.com/cd/0/get/BYrX0i1ilqyDjNZfhB6ruq2WqQAgQUan59p11LCFKOTmtQiFN3h19Kj9wkFl9u_wjeO3uAOxu6xEeEjgSpuavsL0vSydydfTE6neIuf9vgeSn6szP_y7CUMTVKSBfQYxfNlpJTE8ROwhA8WCT92hdmcu/file#
_ReadFileHeaders: domain=uc4e6d0a156efefbb6017fce8317.dl.dropboxusercontent.com, file=/cd/0/get/BYrX0i1ilqyDjNZfhB6ruq2WqQAgQUan59p11LCFKOTmtQiFN3h19Kj9wkFl9u_wjeO3uAOxu6xEeEjgSpuavsL0vSydydfTE6neIuf9vgeSn6szP_y7CUMTVKSBfQYxfNlpJTE8ROwhA8WCT92hdmcu/file#
_ReadFileHeaders: skip http headers
http_skip_headers: http error code HTTP/1.1 400
_ReadFileHeaders: ERROR, http_skip_headers, status=-1
CdnClient_ConnectByUrl: ERROR, _ReadFileHeaders, status=-1
sl_extLib_OtaRun ERROR: Failed on CdnClient_ConnectByUrl
OTA run = -6
OTA: Error with OTA server
[SOCK ERROR] - close socket (82) operation failed to transmit all queued packets

 

Can you see what is happening here? I am usind SDK 1.5.0 and servicepack 1.0.1.15-2.13.0.2

 

BR

  • Ingi's avatar
    Ingi
    4 years ago

    Wonderful, OTA tested and working. Thanks a lot for fast and efficient solution to our problem

  • Greg-DB's avatar
    Greg-DB
    Icon for Dropbox Staff rankDropbox Staff

    It looks like your client is getting a 400, but I just gave that a link a try and it is working for me. Can you print out the full request and response, including both headers and bodies, to see what might be going on there?

    • Ingi's avatar
      Ingi
      Helpful | Level 6

      Hi Greg,

       

      The problem was identified from TI.

       

      It is due to the "#" that appears now in the received Dropbox URL (in the response of the "/2/files/get_temporary_link" API) .

       

      I have got a fix in the code so I will inplement this in it.

       

      I have a problem though that the devices in the field cannot be updated due to this so is there any possibility from your side to remove the "#" in the URL provided in the "/2/files/get_temporary_link" response.

       

      BR

      Ingibergur

      • Greg-DB's avatar
        Greg-DB
        Icon for Dropbox Staff rankDropbox Staff

        Thanks for following up. I see you're referring to the links returned by the /2/files/get_temporary_link endpoint. Per the Dropbox API spec, the returned GetTemporaryLinkResult.link field is only documented as String without a more specific format/domain guaranteed. The exact link format/domain used may vary over time as the Dropbox implementation is updated and maintained, but the link returned should always be valid for four hours.

         

        The implementation for that endpoint has been recently updated, for instance, to return links with a different domain and format, but the returned links are still valid. Specifically, the new format contains a "#" at the end of the link. Per the HTTP spec, the "#" is a reserved character for identifying the beginning of the "fragment" portion in a URI.

         

        One thing we're seeing, however, is that some HTTPS client handle the "#" in the URL incorrectly. HTTPS clients are not supposed to include that portion in requests to the server, but some clients mistakenly do. If that is the issue, you can work around this by removing that trailing "#" from the end of the link before passing it to your client. (Be sure to do so in a fail-safe manner though; the Dropbox API spec does not guarantee its presence, so make sure your code wouldn't fail if it isn't present to begin with.)

         

        I understand you are not able to deploy such an update however, because this is the mechanism you would use to do so anyway. That being the case, I'm raising this with engineering to see if we can accommodate this somehow on our side, though I can't make any promises right now. I'll follow up here with any updates on that.

About Discuss Dropbox Developer & API

Node avatar for Discuss Dropbox Developer & API

Make connections with other developers

795 PostsLatest Activity: 7 days ago
192 Following

If you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.

For more info on available support options for your Dropbox plan, see this article.

If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!