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.

CC3200: SW updates via OTA dropbox failes

Part Number: 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 and you can see these below.


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 = uc4e6d0a156efefbb6017fce8317.dl.dropboxusercontent.com/.../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

  • We are not sure yet.

    Seems like Dropbox made some changes that we were not ware of (we see different issues and are still checking this).

    You are getting HTTP 400 (bad request) on the "get_temporary_link" request.

    I don't see similar issue.

    You can try to contact Dropbox support about this.

    We are also trying to understand the nature of the Dropbox change.

    Note also that they are about to update their certificate to "DigiCert Global Root CA". This error is not related, but the change should happen soon - so be prepared.

    Until the certificate gets changes, we recommend changing the code so upon connection failure (using the current "DigiCert High Assurance Root CA", it will try again with the the new one).

  • Hi,

    I have received following from dropbox. As you can see the request to dropbox seems to be ok, but the simplelink returns 400 anyway.

    Link to the dropbox tread: www.dropboxforum.com/.../552468

    BR

    P.S Thanks for letting me know about the certificate change

  • The problem was identified.

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

    In order to trim the "#" you can use use the following code (replacing the CdnClient_ConnectByUrl() in cc3200-sdk\simplelink_extlib\ota\CdnClient.c):

    _i32 CdnClient_ConnectByUrl(void *pvCdnClient, OtaFileMetadata_t *pResourceMetadata, _i32 secured_connection)
    {
        CdnClient_t *pCdnClient = (CdnClient_t *)pvCdnClient;
        _u8 domain_name[64];
        _u8 req_uri[MAX_CDN_URL_LEN];
        _u8 *cdn_url = pResourceMetadata->cdn_url;
        _i32 status;
    
        /* fix for DropBox issue - i.e. getting trimming the '#' at the end of the URL */
        char* pBuf = (char*)cdn_url;
        if(pBuf = strstr(pBuf, "#"));
            *pBuf = 0;
    
    
        /* extract CDN server name and file name */
        status = http_extract_domain_by_url((_u8 *)cdn_url, domain_name, req_uri);
        if (status < 0)
        {
            Report("CdnClient_ConnectByUrl: ERROR, http_extract_domain_by_url, status=%ld\r\n", status);
            return OTA_STATUS_ERROR;
        }
    
        /* Skip connect server if same CDN server */
        if (strcmp((const char *)pCdnClient->cdn_server_name, (const char *)domain_name) != 0)
        {
            /* close previous CDN server socket */
            CdnClient_CloseServer(pCdnClient);
            strcpy((char *)pCdnClient->cdn_server_name, (const char *)domain_name);
            /* connect to the CDN server */
            pCdnClient->port_num = SOCKET_PORT_DEFAULT;
            do {
                pCdnClient->fileSockId = http_connect_server(pCdnClient->cdn_server_name, 0, pCdnClient->port_num, secured_connection, SOCKET_BLOCKING);
            } while(pCdnClient->fileSockId == SL_ESECT00MANYSSLOPENED); // Retry until previous connection is closed
    
    	if (pCdnClient->fileSockId < 0)
            {
                Report("CdnClient_ConnectByUrl: ERROR on http_connect_server, status=%d\r\n", pCdnClient->fileSockId);
                CdnClient_CloseServer(pvCdnClient);
                if (pCdnClient->fileSockId == OTA_STATUS_ERROR_CONTINUOUS_ACCESS)
                {
                    return OTA_STATUS_ERROR_CONTINUOUS_ACCESS;
                }
                return CDN_STATUS_ERROR_CONNECT_CDN;
            }
        }
    
        /* read file headers, skip all not relenant headers */
        status = _ReadFileHeaders(pCdnClient->fileSockId, pCdnClient->cdn_server_name, req_uri); 
        if (status < 0)
        {
            Report("CdnClient_ConnectByUrl: ERROR, _ReadFileHeaders, status=%ld\r\n", status);
            CdnClient_CloseServer(pvCdnClient);
            return CDN_STATUS_ERROR_READ_HDRS;
        }
    
        pCdnClient->totalBytesReceived = 0;
        pCdnClient->state = CDN_STATE_CDN_SERVER_CONNECTED;
    
        if (pResourceMetadata->flags & METADATA_FLAGS_NOT_SFLASH_STORAGE)
        {
            /* Host storage */
            pCdnClient->pFlcCb = pCdnClient->pFlcHostCb; /* switch (only for current file) to host storage  */
        }
        else
        {
            /* Sflash storage */
            pCdnClient->pFlcCb = pCdnClient->pFlcSflashCb; /* switch back to default SFLASH storage  */
        }
    
        /* save metadata */
        pCdnClient->pResourceMetadata = pResourceMetadata;
    
        return OTA_STATUS_OK;
    }
    
    

    This will require a rebuild of the OTA library and of the application.

    If you have devices in the field, you will need to contact Dropbox and request that they will remove the "#" in the URL provided in the "/2/files/get_temporary_link" response.

    Note due to the frequent changes in the Dropbox environment (of API, authentication methods and certificates) we recommend switching to another CDN server for OTA. Please refer to the library code as an example when porting to another server.

    Note also that Dropbox is about to replace their certificate, and you should prepare for that in advance. See more details in: https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/977073/faq-simplelink-cc32xx-sdk-important-notice-for-customers-using-dropbox-for-ota-updates

  • Ok, thanks for the correction. I will test this next couple of days. But I have searched for the certificate in the OTA code for cc3200 but I cannot locate that. Is that embedded in the code or how can I locate this?

  • Sorry. There is no server authentication using CC3200 so the certificate is not an issue (only on CC3220/3x).

  • Hi Kobi,

    I have tested the correction and it is OK with existing new implementation from Dropbox. But as Dropbox is trying to solve my problem (and others!) with the devices that are already in the field I will wait with marking this as resolved until I see how they can help and test the solution against the hopefully new correction. I hope this is OK.

    BTW:

    Why dont you as company make a cooperation with Dropbox to have a running solution for IOT devices. This market will probably be huge (it is already on its way) and then we can be assured that we have a running solution that will not breake because of changes that are not tested across devices and SW releases. My cooperation with Dropbox has been pleasent and it must be easier for you as a large IOT company to get a good agreement with them.

    I know for the new devices that you also OTA work with Github. This is of course fine, but similar or new problems might occur here as result of changes on their side so this is probably not a garantee that OTA works forever.

    The third solution is of course to have a own OTA solution on own servers. But me (and probably lot of other of your customers) do not whish to host a solution for this if I can avoid it. And for future solutions It would be one of my parameters that a good and reliable OTA solution is in place.

    This is just my humble opinion and I hope it is OK with you to suggest this.



  • Understood. We can't make sure Dropbox will not make changes like this. They are not focused on the IOT markets (many of the issues are only relevant for devices with limited resources such as the simplelink).

    We are trying to find the best partner for this and in the newer devices (CC3220/35) we have options to use also local OTA (i.e. a method where you can update the device using a mobile device that connects to it). In the next release we will add an option to select 2 OTA vendors together (e.g. Dropbox+Github) so you'll have a backup in case one server fails.

    For CC3200 we can only recommend using other servers to avoid issues like that.

  • Hi Kobi,

    Dropbox has now removed the "#" in the link so dropbox OTA is now working again with and without the patch earlier in this thread. Thank you for helping with the solution.