OTA update fails in CC3200

Greg-DB, as you mentioned too (and now I'm pretty sure you're right) the alert is "Close Notify"! A look on the sources shows that there is no way TI client to avoid adding one more empty line at the end... modeling only confirms it. That's it.

Experimenting with other sites shows that most sites ignore additional blanks after requests.

Of course this reflects TLS traffic since TLS wraps HTTP. 🤷

Add:

---

Greg-DB wrote:

... I don't see "Bad Request" or "400" mentioned in this thread before. ...

---

I'm a bit confused of above. 🤔 Did you expect to see it? If you have seen something similar somewhere it had definitely not been encrypted. 😉 Let's recall what we are talking about is encrypted piece of data! That's why it's difficult to discover such a thing on first look.

Thanks!

sundares80 Would you be able to modify a device you have access to in order to have it not send the additional new line as a test? If you can verify that fixes the issue, I can ask the team to look into changing the server to allow that (though please note I can't make any promises on that).

---

Sundaresan Thangeswaran1:

Hi Kobi,

Dropbox says they fixed "new line" issue. Could you please check if that issue resolves our OTA issue without code changes on the device. https://www.dropboxforum.com/t5/Dropbox-API-Support-Feedback/OTA-update-fails-in-CC3200/m-p/771280#M33736

Regards,

Sundar

---

---

Kobi Leibovitch TI__Guru:

I'll be able to check next week. Is it regarding a "new line" within the HTTP headers or at the end of the payload?

Have you checked that you can now complete the update?

---

---

Sundaresan Thangeswaran1:

Hi Kobi,

I don't know where he wants to add a line.

They have not updated the changes in production yet. Anyway, I tested today, and it is not working.

Below is their answer.

"Would you be able to modify a device you have access to in order to have it not send the additional new line as a test? If you can verify that fixes the issue, I can ask the team to look into changing the server to allow that (though please note I can't make any promises on that)"

Please let us know if this fix our issue.

Regards,

Sundar

---

---

Kobi Leibovitch TI__Guru:

so need to better understand where they expect the extra new line.

again, i'll be able to check this only next week (but you can try yourself as the SDK contains all the sources and maefiles.

---

OMG 🤣😂, What kind of comedy!!! 😁 Some comedy actors may left without engagement. Here it's not a play, it's something native.

sundares80 To clarify, we have not made any changes on the Dropbox servers to address this. Здравко helpfully identified a potential cause of the problem, which is that your devices may be sending an unexpected new line at the end of the request body payload. In order to validate if that is the cause of the issue, and if addressing that would resolve the issue for you, I asked you to change one of your devices to make it not send that new line and see if it then works. If so, that would validate that as the cause of the issue so that I could then request that the team address that server-side.

Hi Greg,

Thank you for the clarification.

I have posted your message in the TI forum

I have asked to remove the extra line and test the issue.

Regards,

Sundar

Hi Greg,

TI confirms that removing the new line resolves the issue. 

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1337191/cc3200-ota-error--6-for-dropbox/5203134#5203134

Once you make those changes in production, our devices will do an OTA update without any code modification on the client side. Please correct me if I am wrong.

Regards,

Sundar

Haha... They don't understand still that it's a bug... and they care about how to keep this bug. 🤷

sundares80 Thanks for confirming that. I've raised this to the team to ask that they change the server to accept requests with the extra new line. Again though, please note that I can't promise if/when such a change would be deployed. I'll follow up here with any updates on that.

Also, as Здравко noted, please be aware that the client behavior of sending this extra new line is a bug. If the team deploys a change on the server to accommodate malformed requests with the extra new line like this, such a change should not be considered permanent, and so clients should be updated to not send the extra new line.

I'd also like to thank Здравко again for going above and beyond to debug this!

Hi Greg,

Thank you for the update. Please let us know once you deploy the changes  

Regards,

Sundar

sundares80 I will follow up here with any news on this, but again just to be clear, at this point I cannot say if the team will or won't be deploying any changes for this.

Hi Greg,

I really appriciate your help in finding the RCA for the issue. We don't have any control over the client's device (100K IOT device). The Dropbox API service is the only way to connect to the device. As I mentioned before, this is the highest priority issue in our organization. Since OTA functionality worked before and not working now, few of our customers continuousely started asking for the update. It is affecting the entire business. So please escalate as much as possible and deploy the changes.

Regards,

Sundar

Thanks for the context!

Hi Greg,

We have over 100k of our devices installed globally used by 1000’s of hospitals, pharmacies, food processing and other businesses. The ability for us to update the firmware with OTA functionality using Dropbox is critical for us and clients. As discussed, the function is not working now due to your recent update on the Dropbox API server. We have been waiting for Dropbox to fix the API issue for almost a month, but there is no update from Dropbox. This issue has been escalated to our executives and SensoScientific CTO is questioning when it will be fixed. Can you escalate and schedule a call with your executive/management to further discuss this issue and timing of the resolution. We are trying to address this before it becomes a legal issue and proceeding.

Regards,

Sundar

Thanks for the note. This is still open with the relevant team in engineering on our side. I'll follow up here once I have any update for you.

---

sundares80 wrote:

... We are trying to address this before it becomes a legal issue and proceeding.

...

---

sundares80, It's normal your clients to get angry, of course. But your QA fault doesn't give you base to spur on introduction of bug tolerating software (exactly what you ask for in this thread - the entire thread). Did you prepare new working firmware? Better focus on this and how to help other critical cases. Figure out how a buggy software has reached to your clients and how you can prevent non tested new examples to do the same in future. That's something you definitely can do!

Once you have working firmware, you may prepare updater software (working on computer and/or mobile) to fix your issue on client side, without need to move any devices. With well prepared detailed guide for your clients and demonstration of intents to help them you may be able to reduce the damages.

Don't look for an imaginary guilty side! This may push you in additional (new legal) issues using such a way! This is not a Dropbox issue so you cannot forward the responsibility and if try will likely hit a heavy legal "wall". In spite it's to large extent TI fault, also you cannot do mach there (if you want consult your lawyer though) - keep in mind that such software is provided as is, just for convenience. Despite this "convenience" hit you, it has been and is your responsibility to check before usage of such software for possible bugs (something your QA skipped, as seems).

Good luck.

Hi Здравко,

First of all, there are no bugs or problems in our firmware. For several years, we have been using Dropbox API for pushing OTA updates to our devices installed at our client sites. Recently we learned that your product (Existing Dropbox API) no longer supports the same functionality that we have been using for several years. We are asking when your company will resolve this issue by brining the same functionality back to your API. The concern and legal issue will potentially be between our company and Dropbox, since you are changing the service without advance notice and explanation. If we had advanced notification of this change from DropBox company, we would have planned on updating our devices to use a different API provider, but we were not given such a notice. We currently can not change our devices to point to a different API provider, which will take time and resources.

This is an urgent issue for us and we like to have a meeting with your director and our CTO to discuss timing of this resolution to your product. We hope to resolve this without further delay and escalations.

Regards,

Sundar

---

sundares80 wrote:

...

First of all, there are no bugs or problems in our firmware. ...

---

Hi sundares80,

Hm.. 🤔 Really? And where that malformed HTTP requests come from? 🤷 Is this a bug or (in your definition) no?

---

sundares80 wrote:

... The concern and legal issue will potentially be between our company and Dropbox, ...

---

🤦 Good luck in you look for troubles. In addition to your clients penalties, as seems you will need to pay damages (claim for compensation) to Dropbox too. My advise is to ask competent lawyer in advance. One more lawyer pay would be much less than claim for compensation for lies (such a pretension would be documented lie - would make Dropbox lawyers task easier). All statements on the forum cannot be used as an evidence in front of cоurt, but statement in a case in may be base for other case! Strict follow up for particular standard is not something that should surprise or need somebody be notified. You should state that you had no any idea the Dropbox API use HTTP. What does HTTP standard state otherwise?! Did you read it? Do it before do something stupid.

Take care for your interests! 😉 I don't protect anybody. Emotional movements very often lead to bad consequences. Learn it in an easy way not in a difficult one.

sundares80 I wanted to let you know that this is still open with the team, and they're currently working on changing an option in our systems that might address this for you. Please note that we can't guarantee this will help.

That change is not deployed yet. I will follow up here to let you know once that change has been fully deployed and ask you to confirm if it does or doesn't help.

Thanks for the update, Greg.

Once you deploy, the same day we will test and let you know about the result.

Regards,

Sundar

sundares80 That change has been fully deployed now. Unfortunately, in my own testing it doesn't appear this change helps, but please do still try your actual device and let me know if it does or doesn't help.

Hi Greg,

I have tested just now, but i see the same error. I did not get the temporary download link.

Regards,

Sundar

sundares80 Thanks for checking. I'll let the team know that didn't help.

---

Greg-DB wrote:

... That change has been fully deployed now. Unfortunately, in my own testing it doesn't appear this change helps, ...

---

Greg-DB, I don't know what's fully deployed, but if that deployment has not been dropped in meantime, there is no any effect of it. I just checked and as seems additional new line is still count as an broken request (as is), so no any workaround.

Hi Greg,

Any update?

Regards,

Sundar

sundares80 I don't have any news on this right now. I'll check in with the team.