• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 225 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC3220SF: Dropbox OTA, Error 400

CC3200: CC3200

Parthiban Elavarasan
Prodigy 120 points
Part Number: CC3200

Having issue in connecting to Dropbox for OTA. Facing CDN error while trying to connect by presigned url. I would like to have more information on whether the issue is with TI or I need to follow up with dropbox. Below is my device request and response.

INFO] [OTA] Update Check, found 1 files
OtaClient_ResourceMetadata: call http_build_request

[INFO] [OTA] HTTPClient_SendReq
POST /2/files/get_temporary_link HTTP/1.1
host: api.dropboxapi.com
User-Agent: api-explorer-client
Authorization: Bearer Token #####################################################
Content-Type: application/json
Content-Length: 45

Response

[ERROR] [OTA] CdnClient_ConnectByUrl: ERROR, http_extract_domain_by_url, status=-1
[ERROR] [OTA] sl_extLib_OtaRun ERROR: Failed on CdnClient_ConnectByUrl
[INFO] [OTA] [END_OF_UPDATES]
[INFO] [OTA] close OTA client and CDN client and back to IDLE

  • 0
    Prodigy 120 points

    Adding the dropbox response


    HTTP/1.1 400 Bad Request
    Content-Length: 1005
    Content-Type: text/html
    Vary: Accept-Encoding
    X-Dropbox-Response-Origin: local
    Date: Mon, 04 Mar 2024 17:25:08 GMT
    Server: envoy
    Connection: close

    <!DOCTYPE html>
    <html>
    <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Dropbox - 400</title>
    <link href="">cfl.dropboxstatic.com/.../error.css" rel="stylesheet" type="text/css"/>
    <link rel="shortcut icon" href="">cfl.dropboxstatic.com/.../>
    </head>
    <body>
    <div class="figure">
    <img src="">assets.dropbox.com/.../target-miss.svg" alt="Error: 400"/>
    </div>
    <div id="errorbox">
    <h1>Error (400)</h1>Something went wrong. Don't worry, your files are still safe and the Dropbox team has been notified. Check out our <a href="">status.dropbox.com">Status Page</a> to see if there is a known incident, our

  • 0 in reply to Parthiban Elavarasan
    TI__Guru 63006 points

    Yes, we are familiar with this.

    Apparently Dropbox changed something recently and we are trying to understand what. 

    You can try to contact Dropbox directly to get explanation for this error. 

  • 0 in reply to Kobi Leibovitch
    TI__Guru 63006 points

    We'll update here if we find the root cause and/or a fix.

  • 0 in reply to Kobi Leibovitch
    Prodigy 120 points

    Kobi,

    I got response from Dropbox mentioning request built and sent from the device could be wrong and nothing changed on dropbox side is causing the failure. Can you help me understand if anything wrong with the second request sent below. 

    Getting proper response for the first request but for the second one below HTTP/1.1 400 Bad Request

    First Request

    POST /2/files/list_folder HTTP/1.1
    host: api.dropboxapi.com
    User-Agent: api-explorer-client
    Authorization: Bearer ######################################
    Content-Type: application/json
    Content-Length: 24

    { "path": "/pkg_00098" }


    Second Request

    POST /2/files/get_temporary_link HTTP/1.1
    host: api.dropboxapi.com
    User-Agent: api-explorer-client
    Authorization: Bearer ########################
    Content-Type: application/json
    Content-Length: 45

    { "path": "/pkg_00098/f80_sys_mcuimgA" }

  • 0 in reply to Parthiban Elavarasan
    TI__Guru 63006 points

    We are facing the same with with CC3220 (which uses a different code). Code that used to work stopped recently.

    Something was changed on the Dropbox side. We are still not sure why as the packet seems correct.

    One thing i noticed is that if the get_temporary_link is sent after a delay (e.g. if you just put a breakpoint before it is sent and resume immediately when it stops) - the packet is being accepted (at least at the host side - printing the packet content - the original packet and the delayed one seems identical - we haven't check over the air).

    Since we don't understand the root cause - we don't have a formal fix yet.

    We'll publish here (and in other relevant  threads when we have one).