Embedded device Over the Air download fails

[flygecko]

Hi,

  I have devices that have successfully been connecting to api.dropbox.com for several years for code download.  Yesterday they started not being able to setup a socket connection to the server.  Nothing has changed in the devices.  The connection to the server is a normal part of the device startup and had been working fine.  Does anybody have any ideas that could help?  My devices are not doing anything new and I was wondering if there is a problem with the API server.

Thanks!

Vic

[Greg-DB]

I'll be happy to help with any issues you're having with the Dropbox API, but I'll need some more information. Please reply with:

• the name and version number of the platform and SDK/library you are using, if any
• the steps to reproduce the issue, including relevant code snippet(s), but don't include any access token(s)
• the full text of any error or unexpected output

[flygecko]

We are using a Texas Instruments CC3200 embedded arm controller.  The connection code is provided by TI and has been running for about 3 years with no problems.  The problem is reproducible on our devices just by bring up the device.  This worked 2 days ago and stopped working yesterday.  We did not write the OTA code.  Additionally no devices have been updated in many months.  Here is the error we receive:

_ReadStatFile: ERROR in sl_FsOpen, status=-11
sl_extLib_OtaRun: call OtaClient_ConnectServer OTA server=api.dropbox.com
OtaClient_ConnectServer: http_connect_server api.dropbox.com
http_connect_server: ERROR Socket Connect, status=-208
OtaClient_ConnectServer: ERROR http_connect_server, status=-1
_OtaCleanToIdle: close OTA client and CDN client and back to IDLE
sl_extLib_OtaRunERROR: OtaClient_ConnectServer, status=-1
[00:00:14.0386] OTA run (-3)
[00:00:14.0389] OTA: Unable to connect to Server

The error codes returned are defined here...

#define SL_SOCKET_ERROR_E (-208) /* Error state on socket */

#define RUN_STAT_ERROR_CONNECT_OTA_SERVER -3

Nearest we can tell the connection is not being set up.  This could mean that it is because the server is not seeing us, or is not responding to us.  Sadly the error messages provided by the library code are not a great help.

Thank you for the help.

[Greg-DB]

I see, thanks for the information. Do you know if your HTTPS client does or doesn't support SNI? HTTPS clients should handle that automatically, but if this one doesn't, that might be the cause here. 

[flygecko]

The Texas Instruments CC3200 does not support SNI.  These systems worked flawlessly on Wednesday.  Has Server Name Indication become a requirement since then?

Vic

[Greg-DB]

Thanks for confirming that. Yes, the Dropbox API servers do now require SNI. I'm raising this with the team. I'll follow up here once I have an update on that.

[flygecko]

Hardware support is required for this and the CC3200 will never be able to support this.  So, any help would be greatly appreciated.

[Greg-DB · Accepted solution]

The Dropbox API servers should no longer be requiring SNI. Please try again and let me know if you're still seeing any issues. Thanks!

[flygecko]

Hi Greg-DB,

  Thank you so much, that did the trick.  All of our devices are now able to connect to the servers.  Is the turning off of SNI a permanent solution?  If not do you know when it will turn back on? If it will be turned back on we need to plan how to work around it.

Thanks,

Vic

[Greg-DB]

@flygecko The team is planning on keeping the current SNI-optional configuration. We do recommend modernizing your client/libraries though, e.g., to support SNI, and the latest transport security protocols, etc.