Child Item

OTA for CC3200 Corrupted Download file.

We are using dropbox to host update files for a hardware device that uses a cc3200. Last week our devices were no longer able to retrieve a file update file from dropbox. When we test the download it is returning an invalid file of the correct size.

Were any changes made in the past few weeks that would cause this to happen?

What were these changes?

Have any other customers reported this issue?

We are confident that this is a dropbox issue, we ran a local test redirecting traffic to a local server that returns the same file and everything works. But if we download the same file from dropbox it fails.

Screen Shot 2022-02-17 at 3.58.31 PM.png

You can see that in the file dropbox returns it is appending a few bytes at the front.

Thanks for checking.

Find more posts tagged with

Developers

Accepted answers

Greg-DB

Update: we have extended the timeline and are planning to keep the current behavior until at least 3/14.

All comments

Greg-DB

From this description, it sounds like this is due to recent updates to the server back-end for some Dropbox functionality to use "Transfer-Encoding: chunked" (and accordingly not return the "Content-Length" response header) on HTTP/1.1. HTTP clients are supposed to automatically handle this, but it's possible yours doesn't.

Please note that Dropbox does not guarantee which encoding will be used or that the "Content-Length" HTTP response header will always be present on the responses for these URLs. When the server is using "Transfer-Encoding: chunked" for the response, "Content-Length" is omitted. While the Dropbox servers use the HTTP protocol, exactly which features they use may change over time.

If your client isn't properly decoding the HTTP message, it could corrupt the data you save. That is, it would be incorrectly saving the raw response body, including some additional HTTP chunk data, as the file.

If that's the issue, you should update your client/code to support "Transfer-Encoding: chunked" (and not assume the "Content-Length" response header will be present). Or, switch to HTTP/2, where "Transfer-Encoding: chunked" is not used (and the "Content-Length" response header should be present).

However, in order to temporarily accommodate clients that don’t properly support automatically handling “Transfer-Encoding: chunked”, we’re temporarily rolling back this change, so that these links will no longer use “Transfer-Encoding: chunked” and will instead return “Content-Length” on HTTP/1.1. We will begin rolling that out shortly, likely today. That will be in place until around 3/1. At that point, we will begin using “Transfer-Encoding: chunked” and no longer returning “Content-Length” on HTTP/1.1 again.

Going forward, please ensure that your clients are able to automatically handle both chunked encoding and non-chunked encoding automatically.

Здравко

@justindaw wrote:
...
You can see that in the file dropbox returns it is appending a few bytes at the front.
...

🙂 Not only at the front, for sure! There are 2 bytes at the end too, at least. May be some more inside.

34 30 30 30 0d 0a
🡓  🡓  🡓  🡓  🡓  🡓
4  0  0  0  CR LF

The above means you have a chunk of data. Chunk size is 4000 Bytes and at the end are 2 more bytes (Carriage return and Line feed). If that chunk is the entire data, that's all. Otherwise follows new chunk's packet - new size (encoded to ASCII digits as in your example) and CR LF pair, actual chunk of data, and ending CR LF pair. The last repeats as many times as need to transfer all data.

Hope this sheds some light on chunked transfer encoding. 😉

justindaw

Can you let me know when that rollback was completed? We are still having issues updating the devices.

We will not be able to update all of our devices in the field, used by consumers, by 3/1. This method, along with the sample code, of doing OTA Updates was supplied by texas instruments for the CC32XX chipset. While we understand that dropbox does not guarantee which encoding will be used you should be aware that this change will likely affect a lot of devices. Likely there are millions of devices in the wild that are going to have this issue if you change back to chunk encoding. Some of these devices, such as ours, only receive updates occasionally and they will be unware that this issue affects them until months from now.

Greg-DB

@justindaw Thanks for the feedback! The rollback is still planned, but was delayed for unrelated reasons.

justindaw

@Greg-DB any timeline on the rollback?

Greg-DB

@justindaw I don't have an update right now. I'll follow up once I do.

justindaw

@grex Any update on the timing of the rollback?

Also, who do we need to talk to about making this rollback longer than a week? The process of updating devices for us will take much longer than that.

Greg-DB

@justindaw The rollback has just been started. It will take some time before it's fully deployed though. I've sent your feedback about the timeline along to the team, but I don't have an update on that right now.

justindaw

@Greg-DB thanks for the update on the rollback. I will continue to follow up on this as it is a critical item for us.

justindaw

@Greg-DB Any word on a timeline for restoring this change? again, We really don't want this change to move forward this quickly. We are working on updating our firmware but it will take some time to finish testing and roll it out to consumers.

Greg-DB

@justindaw I don't have an update on that yet. I'll let you know once I do.

justindaw

@Greg-DB we need to know if you are rolling the change back tomorrow. We have to update customers about this.

Greg-DB

@justindaw Thanks for the note. I'll check in with the team.

binho_ogawa

@justindaw Could you share how you fixed the problem?

Greg-DB

Update: we have extended the timeline and are planning to keep the current behavior until at least 3/14.

justindaw

@Greg-DB thanks for the updated time. We do appreciate it.

We are notifying our user base to update, however not all of them will. So we continue to request that the change is not rolled back. Please consider that this impacts not only us but a number of other companies that use similar OTA update processes.

Greg-DB

@justindaw Thanks for the additional feedback!

justindaw

@Greg-DB are you planning on rolling out this change on the 15th? We need to let our customers and service staff know if they will be able to update next Monday.

Greg-DB

@justindaw We're working on some updates that should allow us to avoid that. I should have an official update on this on Friday.

Greg-DB

Update: the team has been able to complete some further updates to our infrastructure to be able to support the previous non-chunked behavior going forward indefinitely. That means that we plan to continue returning Content-Length (and not 'Transfer-Encoding: chunked') in the future and will not be reverting this on 3/14. (Regardless, for HTTP compatibility in general, we still recommend you make sure your HTTP clients support both types.) Hope this helps!

justindaw

@Greg-DB Thanks for the update! Let the team know that we greatly appreciate this.