This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3100: OTHER_SIDE_CLOSE_SSL_DATA_NOT_ENCRYPTED

Part Number: CC3100

Hello,

I'm seeing a similar issue here where the I'm getting this error: OTHER_SIDE_CLOSE_SSL_DATA_NOT_ENCRYPTED (2). It is always coupled with SL_ESECCLOSED (-452).

I'm using FreeRTOS.

The answer given to a similar questions was:

"TCP connection was closed from remote side (server side). You need to close connection before timeout at server side or ignore this event.". What does this mean exactly. Why do I need to close the connection prior to which timeout?

I've been in contact with AWS (the broker we use) and they're saying the connection on their end is solid, no TLS/encryption drops.

When this occurs we then see MQP_ERR_NOTCONN (-7) errors immediately after.

  • Hi,

    Usually it means that the other side sent an SSL alert with 'close notify'. This is why we need to close the underlying socket and open again.

    if you have a sniffer, it would shed some light.

    how often does it happen and have you noticed a specific pattern with regards to these errors?

    Shlomi

  • The error pattern is always in this order:

    (2) OTHER_SIDE_CLOSE_SSL_DATA_NOT_ENCRYPTED

    (-452) SL_ESECCLOSED

    (-1) SL_SOC_ERROR?

    (-7) MQP_ERR_NOTCONN

    (-7) MQP_ERR_NOTCONN

    There doesn't appear to be a pattern to the frequency. It happens hours apart, sometimes days apart.

    Can you give me an example of how I would handle the scenario you presented? Also, how does the "close notify" alert get to me? I don't see an API in the Host Driver that would help with that. I'm also not familiar with the notification. What reasons are there for the MQTT broker to report that?

  • Hi,

    I don't know why the other side closed the socket (although they claim that they don't) but on our side this is what it looks like. Generally, if we call sl_Recv() which is called underneath the MQTT receive API, and we get 0, it implies that the other side closed the socket (we expect a positive number indicating the number of received byte or a negative number indicating the error).

    To handle this scenario, you need to close the socket and reconnect. Is this what you are doing to recover? the "close notify" alert is the translation of this error when you try to receive data over the socket.

    Regards,

    Shlomi