OTA update fails in CC3200

Hi Greg-DB,

Yes, I may got confused about the exact code. I tried to reproduce it right now - unsuccessful.

There is other strange situation though. Dropbox server refuses to renegotiate! Despite this activity support is optional, it's highly recommended (according to RFC 5246). About Client Hello:

---

When this message will be sent:

   When a client first connects to a server, it is required to send

   the ClientHello as its first message. The client can also send a

   ClientHello in response to a HelloRequest or on its own initiative

   in order to renegotiate the security parameters in an existing

   connection.

---

About "TLS protocol issues":

---

While renegotiation is an optional feature, supporting it is
highly recommended.

---

When some client tries renegotiation, Dropbox response is:

Received Record
Header:
  Version = TLS 1.2 (0x303)
  Content Type = Alert (21)
  Length = 18
    Level=fatal(2), description=no renegotiation(100)

 Hm...🤔 According documentation, such a message should be warning, not fatal!  Again, RFC 5246 states:

---

no_renegotiation

   Sent by the client in response to a hello request or by the server

   in response to a client hello after initial handshaking. Either

   of these would normally lead to renegotiation; when that is not

   appropriate, the recipient should respond with this alert. At

   that point, the original requester can decide whether to proceed

   with the connection. One case where this would be appropriate is

   where a server has spawned a process to satisfy a request; the

   process might receive security parameters (key length,

   authentication, etc.) at startup, and it might be difficult to

   communicate changes to these parameters after that point. This

  message is always a warning.

---

This is a step aside from OP, but I just discovered it and that's why I'm mentioning. Such a message doesn't let a chance to client to decide whether to proceed further (without renegotiation) or not! This is not an issue in particular situation since there is no preceding handshake in the shared pcap, so that alert cannot be such a type (despite no way to be certain since encrypted).

There is another thing that may be interesting in context of OP. As can be seen (if we assume the alert is "close notify"), it comes from server side, not from client side (as it usually does). Such thing is possible only when in the request is header "Connection: close" or I was not able to reproduce it in other situation at least. So to be possible confirmation or rejection of this supposing (inappropriate header), sundares80  should send plain request to pseudo-server (like netcat, for instance) and see if there is some unintentional header. I suppose wouldn't be possible SSLKEYLOGFILE usage since most probably the application doesn't support it.

Здравко Thanks for writing that up! I'll pass it along to the team.