OTA update fails in CC3200

---

sundares80 wrote:

... The only thing we can do is perform an OTA update, which is currently not working due to your changes. ...

---

Hi sundares80,

I don't know what do you mean with "your changes", but I'm a regular Dropbox user, like you, and complain about different imperfections (very often bugs), the same like you do. I can "remove" something as much as you can - neither more nor less. Following this context line, did you check your code for bugs? 🧐 I'm already pretty sure there are such that lead to the result you're observing. You can model the behavior of your device (and your code accordingly) with following curl command:

TOKEN="PUT YOUR ACCESS TOKEN HERE"
NL=$'\r\n'
curl -v https://api.dropboxapi.com/2/users/get_current_account -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -H 'content-length: 4' --http1.1 -d "null$NL" -: https://api.dropboxapi.com/2/users/get_current_account -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' -H 'content-length: 4' --http1.1 -d "null$NL" > /dev/null

The command curl is more stable and continue work, but the same "noise" in the communication may be observed. Comment this with your TI support if you want. Or rather if they want to do such a commenting with you... 😁 Would be pretty inconvenient to them!

Good luck.

PS: sundares80 don't use their buggy libraries, but rather some third party library or reimplement the HTTP communication yourself to passaround current bugs.

ЗдравкоThank you for your analysis. Yes, we agree. We have to redesign our HTTP client library. but I cannot access the physical IOT device since it is installed in multiple locations in the US and Europe. The only way I can update the client code is by doing an OTA update.

Greg-DB/Здравко

As per the packet capture, our IOT device support below chipers.

When I scan drop box server with below link, I see only warning message (Weak cipher) for one cipher which is used by the device. If you help to change it to green, I belive this issue is going to resolve.

https://www.ssllabs.com/ssltest/analyze.html?d=api.dropbox.com&s=162.125.8.19

Regards,

Sundar 

sundares80, I don't want disappoint you, but the cipher in use has nothing to do with your issue. Even more: Any server cannot select something client hasn't provided! If you count that as some possible other issue - it's your responsibility.

sundares80 While that SSL Labs SSL Server Test tool is not made by Dropbox and I am not an authority on it, my understanding is: The cipher being marked orange instead of green only indicates that the cipher is considered "weak", and does not indicate anything about the the server's use of the cipher. The inclusion of the cipher in that list at all indicates that the server supports that cipher. That "weak" is a description of the cipher itself, not the server configuration.

That being the case, it's not possible for us to change that cipher from orange to green. We could only remove it from that list for our servers entirely.

Actually there is a way to be solved discussed issue. The existence of empty lines is not something defined in HTTP standard, but also it's not something denied (not explicitly at least). 😉 Many present day servers also ignore such extra blank symbols, if any, at the request end. I don't know if Dropbox may decide to do the same, but if so that wouldn't be an issue anymore. (No more Bad request response - provoked by this empty line - directly following OK response)

Good luck.

Здравко I can reproduce the 400 Bad Request using your code snippet, but can you clarify how you determined that this "Bad Request" issue is the cause of the problem originally reported in this thread? I don't see "Bad Request" or "400" mentioned in this thread before. The original poster seems to have reported the issue as being in the TCP/IP or TLS layer instead. Thanks!

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.