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.

SL_IP_LEASE_EXPIRED(2) error and SL_ESECCLOSED (-452)

Part Number: CC3100
Other Parts Discussed in Thread: CC3200

Hello,

Opening this question again as the replies to the last one were not visible to anyone: https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1109936/cc3100-reopening-sl_ip_lease_expired-2-error

I am trying to get some help understanding the SL_IP_LEASE_EXPIRED (2) error.

Apparently SL_IP_LEASE_EXPIRED is related to is an AP DHCP Server - IP Release reason. I assume this means the CC3100 was unable to renew the IP with the DHCP server of the AP - either because of an internal failure or because the AP is rejecting the renewal? I see this error sometimes as well: SL_ERROR_DHCP_CLIENT_RENEW_FAILED (-100). I assume they're related.

Device Info:

  • MQTT enabled
  • Station Mode

The device is never configured for AP mode. Our devices are only ever acting as a client. Unfortunately I'm unable to get NWP or sniffer logs as these devices are in-field.

Singling out out a few of these devices, I see that they're always surrounded (happening around the same time) by error number -452 or 109/110.

From what I've learned -452 means the broker terminated the TLS session but the TCP connection is still up.

The error is returned by sl_Recv()

A few points:

  • Theory that multiple devices with the same Client ID (MQTT) being used
    • Not possible. All devices have their own unique ID. Confirmed with broker logs during the times this error was triggered.
  • Broker logs do not display any indication of a TLS session termination

This seems to happen with a large number of our devices. I have not be able to reproduce on my own. Just trying to get some guidance one what can be done to mitigate or avoid this.

Thank you

  • Hi Wilmer,

    SL_IP_LEASE_EXPIRED (2) is part of an async event sent to the host when an IP address is released by a station. This is outlined in Table 9-4. Event Parameters in Chapter 9 AP Mode of the CC3100/CC3200 User's Guide. This should only be seen when the device is in AP mode.

    SL_ESECCLOSED (-452) means that the secure layer is closed by the other side. Are there any clues at all on the cloud side as to why the socket was closed by the server? Does your cloud configuration support TLS?
    Are you using the most up to date versions of the CC3100 SDK (v1.3.0) and service pack (v1.0.1.15-2.14.0.0)?

    Best regards,

    Jesse

  • I see... I'll take precautions to validate and ensure the devices are always in station mode.

    I haven't found any clues at all. The logs show regular usage of the device. We use AWS IoT as the broker and it does support TLS.

    • We publish about every ~5 minutes regularly. Other data is pretty irregular, so it’s hard to give an interval; but should be multiple time a day from each device.
    • From internal logs (around the time this error occurs), typical usage seems to be what I’m seeing:
      • Periodic connection-state messages
      • data being successfully transferred to and from the device
      • I’m noticing that the connection does recover; but soon after (typically a couple of minutes) the same error is triggered. And this keeps happening periodically.

    Yes, NWP is currently version 2.14.0.0. The Host Driver codebase was taken from the CC3200's SDK (v1.5.0). I was advised to do so in: e2e.ti.com/.../cc3100-latest-service-pack-version

  • Hi Wilmer,

    You mentioned that you're only seeing this issue on devices that are in the field but you haven't been able to reproduce the issue on your own, correct?

    You may need to get NWP logs and/or sniffer logs of a device observing the issue or reproduce it in order to debug further with regards to the CC3100.

    Best regards,

    Jesse

  • If I'm ever able to reproduce or get a chance to go on-site I will reply here or create a new thread. Thank you

  • Hi Wilmer,

    Thank you. We will close the thread for now and await your update.

    Best Regards,

    Ben M