Over the air download via API fails today, worked yesterday.

Thanks Greg.

Look forward to hear from you.

We have the same problem here with more then 100K devices in the market at the moment. Therefore we ask you to find a solution to this as well.

Hello Greg, please escalate this issue because there are alot hundreds thousands of user that have an issue about this. Only our users are more then 100K.

IOT_Developer I have escalated this to engineering. I'll follow up here once I have an update.

Hi Greg,

  I would like to add my voice to the chorus of people asking for this to be escalated.  I have thousands of devices that are affected by this also, and it would cost us a prohibitive amount of money to replace them in the field.  Additionally the customer support issues would be a nightmare.

Thanks,

Vic

flygecko Thanks for the additional feedback!

Hi Greg,

We also have 100K devices installed in the different locations in USA. We cannot able to do OTA. Our customers are affected because of this and it impact our business.  Please escalat the issue and revert the recent changes ASAP.

Thanks

Sundar

@Greg seems like a very big issue to me.

I can't imagine honestly 300K people complaining to dropbox. Can't you? 

Do you have any updates?

Thanks for the feedback! 

I have escalated this, and I will follow up here once I have an update. 

I have the same problem. The update is very important on my device. My company already has thousands of equipment installed.

@Greg, we are facing the same issue. we have more than 10K devices in field and we can't update them because of this issue. it has become a nightmare for us. please fix this as soon as possible.

Thanks again for the information! I'll reply here as soon as I have any news on this.

The team has developed a change to reduce the link length, which is tentatively planned for deployment tomorrow. I'll follow up here with an update when that's done.

Thank you Greg for the update, waiting for the solution update.

Hello Greg, any updates?

IOT_Developer The deplyoment is still planned for today. I'll follow up here once that's done.

Hello everyone. We have just come across this issue today. We also have a few hundred devices on the field and have been successfully doing OTA updates for TI CC3200 with Dropbox API since 2015 (back when APIv1 was still in use).

We are constantly getting links with 557 bytes in lenght and there is no feasible way to fix this in firmware for devices on the field.

Anxiously waiting for a fix!
 
Thanks!

Good news, this team worked on this, and was able to reduce the link length back to under 500 bytes. You should be able to request the shorter links again now. Please try it and let me know if you're still seeing any issues.

Please note, however, that the Dropbox API specification still does not guarantee a maximum length for this 'link' value. That being the case, please update your app(s) to accommodate a 'link' of arbitrary length (or at least, of significantly larger length).

I have also sent this along to the team as a feature request to codify a maximum length for the 'link' in the specification, however at this point I can't promise if that is something that will be done. The temporary link implementation on the Dropbox API backend is not trivial, and involves encoding certain authorization data in the link. The size of this data can vary.

Finally, an important security note:

Based on the context I've received around this issue, if I understand correctly, this is being used for updating devices over-the-air, by embedding pre-generated access tokens for a single specific Dropbox account directly in to the devices. The devices call a number of Dropbox API endpoints using that access token, such as /2/files/get_temporary_link (the result of which is used to download a firmware update payload).

The Dropbox API was designed with the intention that each user would link their own Dropbox account however, in order to interact with their own files. It is technically possible to connect to just one account as is being done here, but we don't recommend doing so, for various technical and security reasons, especially in client-side apps like this.

One of the main issues is that client-side apps can't keep secrets. A malicious user could extract the hard-coded access token from the app, and use it to access the Dropbox API directly to perform any operation (bypassing any access controls your app might have attempted to enforce). For instance, in this scenario, they could upload their own malicious payload, which would then be distributed to the other systems via the existing over-the-air update mechanism.

Of course, the actual difficulty to extract the access token and perform an attack depends on a variety of factors, and your organization can choose what level of risk you're willing to accept. Please contact a security professional for any general security advice.

For the above listed reasons though, I do not recommend using the Dropbox API in this manner. Instead, a typical CDN may be a better way to distribute updates. I've also sent this along as a feature request for a safe way to use the Dropbox API in this manner, but I likewise can't promise if this is something that would be implemented.

Hello Greg,

Please thank your team on our behalf and on behalf of 100K users, at least on our side.

Your statement is noted and we will proceed with firmware changes ASAP.

Hello Greg,

We have tested and it works.

Could you please send me dropboxe's address using in a private message (info at gcdis.com)

I would like to send you and your team a gift for Christmas.

Also do not forget to mention the team member names for the Christmas cards.

Hi Greg,

Thank you and your Engineering team.  We have tested the OTA on few Chips in field and it worked. 

Embedded Devices are limited by memory and this device CC3200 has very tiny memory. It will be good to know the maximum size of link that Dropbox might implement in the future. We are thinking of allocating 1200 bytes. 

Thank you Greg!

We are allocating 768 bytes for the temp link (up from 512).

For the other CC3200 users out there: it seems that increasing the size of OtaFileMetadata_t.cdn_url (on ota_api.h) is not enough! You can still get a memory leak on req_uri (in CdnClient_ConnectByUrl), as part of the temp link will be copied to this buffer which originally has 400 bytes!

We were able to find this leak just because, by chance, it was affecting a data structure holding proxy data, which breaks all communication!

If anyone knows of any other additional changes that have to be made in order to accommodate the larger Dropbox temp link please share here! Let's help each other out!

Thanks!

Hello Greg,

It seems that we are having problem again with the returned url, can you please check?

Kindly note that we did change our firmware update process to Amazon IoT but unfortunately we do have a significant number of users that did not update yet to the new firmware and are having issues because of the returned URL.

You can see for yourself that the API calls have been reduced noticeably. Nevertheless, as you already know, transition from one system to another is not linear as we don’t have the power to drive everyone in making the transition within the required time.

With this point in mind, we kindly ask for your understanding and support in returning links shorter for another 2 months. On our side we will put all our efforts in communicating a final notice to our customers so that they make the transition, thus eliminating api calls to dropbox prior to the expiration date.

George

IOT_Developer Thanks for the report! I'll be happy to look into this for you, but I can't make any promises. First, for reference, can you let me know:

• Is the issue again with the length of the link returned by /2/files/get_temporary_link?
• When did you start seeing this issue again?
• What length were you getting before then?
• What length are you getting now?

Thanks in advance! 

Greg-DB  Thanks for your prompt response. The issue again is with the link returned. 

It all started happening this monday.  Before that it was less than 400 bytes and we suddenly see it crossing 512 bytes which is the limit.