CC3200-LAUNCHXL: recv socket API returns error -100

Hi Nagaraj,

The -100 error is SL_ERROR_DHCP_CLIENT_RENEW_FAILED (-100) /* DHCP client error */, so it appears the DHCP client is unable to renew its lease.

Are you using the CC3200 as a WiFi STA or AP? If STA, then this could be related to the router you are using. 

Best regards,

Jesse

Hi Jesse,

              Thanks for your reply, We are using CC3200 as WIFI STA mode , Socket API will be return only socket error code right, But this error was mentioned under Device error code. The error code -100 or -452 code will occur frequently from recvl socket API if WiFi rssi is between -56 to -73, mostly frequently this occurred at WiFi rssi -72 and sometimes WLAN disconnected with reason 109 and 110 error code.

We are using Deco mesh network router, And distance between CC3200 and WiFi router approximately ~10 meters.

Thanks,

Nagaraj

Hi Nagaraj,

Just a comment...

I think there is different meaning of error code -100 at your case. It is not a DHCP client error, but SL_API_ABORTED. Because I think it is not possible to be returned DHCP error from send/receive socket API.

Unfortunately SL_API_ABORTED error does not signalise anything good. Meaning of this error is something bad happened with host driver of NWP. What error do you see before returning -100? Do you see any asynchronous handler before returning error?

btw... why do you use CC3200 devices instead of CC3220 or CC235? do you have latest ServicePack inside device? Do you use SDK 1.5?

Jan

Hi Jan,

      We did not get the roadmap/visibility in terms of the CC3220/CC235 when we started our project, we have used SDK 1.5 and  ServicePack_1.0.1.15-2.14.0.0  flashed into the device, Which asynchronous handler will be expected  when this type of error code occurred?

Thanks.

Nagaraj

Hi Nagaraj,

Yours SDK and ServicePack should be fine.

I am not able say what exact asynchronous handler you can expect. Anything via SimpleLinkGeneralEventHandler() or SimpleLinkWlanEventHandler().

Jan

Hi Nagaraj,

-452 (SL_ESECCLOSED) means the server is closing the secure layer but the TCP connection is still up. Can you provide any code snippets or step through the code to see where exactly these errors are coming from?

For more information regarding the WLAN disconnect reasons 109 (SL_WLAN_DISCONNECT_ROAMING_TRIGGER_BSS_LOSS) and 110 (SL_WLAN_DISCONNECT_ROAMING_TRIGGER_BSS_LOSS_DUE_TO_MAX_TX_RETRY), please see these answers:

• CC3200: Disconnection Error 109 / 110
• CC3200: Connection Errors, Disconnection Reasons, and Their Differences (109, 110, -102,-109,-110)

Best regards,

Jesse

Hi Jesse,

              Please find below snippet for your reference. In recv_handler_task recv function returning the -452 and sometimes -100.

void recv_handler_task(void * Arg)
{

while(1)
{
uint32_t ulEvent;
fd_set Read_FD;
FD_ZERO(&Read_FD);
FD_SET(pstHandler->Socket, &Read_FD);

timeval stTimeOut;
stTimeOut.tv_sec = 2;
stTimeOut.tv_usec = 0;

do
{

int32_t iStatus = select(sock + 1, &Read_FD, NULL, NULL, &stTimeOut);

if(iStatus == 0) // Timeout check try again.
{
continue;
}
else if(iStatus == -1) // Socket error.
{

DBG_MSG("select error\r\n");

break;
}

// read MQTT data
RxSize = recv(sock, pstHandler->RxBuffer,                    
1440, 0);                                                       // here it is returning -452 and sometimes -100
pstHandler->RxSize = RxSize;
if(RxSize <= 0)                                                                
{


DBG_MSG("recive error\r\n");
close(sock);
break;
}
parser_handler(pstHandler);

}while(1);
}
}

int32_t connect()
{
sl_NetCfgSet(SL_IPV4_DNS_CLIENT,0,sizeof(SlNetCfgIpV4DnsClientArgs_t),(unsigned char *)&DnsOpt);*/

int32_t lStatus = gethostbyname((signed char *)pstConnect->Host.cAddr_c,
pstConnect->Host.Size, &HostIP, AF_INET);

if(lStatus < 0)
{
DBG_MSG("Failed to resolve host address\r\n");



return 0;
}




sockaddr_in LocalAddr;
LocalAddr.sin_family = AF_INET;
LocalAddr.sin_port = htons(MQTT_PORT);
LocalAddr.sin_addr.s_addr = htonl(HostIP);

uint32_t ulCypher = SL_SEC_MASK_TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256; // -155 -155 -155

Status = setsockopt(Sock, SOL_SOCKET, SL_SO_SECURE_MASK, &ulCypher, sizeof(ulCypher));
if (Status < 0)
{

close(Sock);
return -1;
}

Status = setsockopt(Sock, SOL_SOCKET, SL_SO_SECURE_FILES_CA_FILE_NAME,
ROOT_CA_FILE, strlen(ROOT_CA_FILE));

if (Status < 0)
{
body_len = sprintf(stGateway.Json_Buffer,JSON_GATEWAY_INFO_ERROR_MESSAGE,strtcTime.sec,stMqttConfig.ThingName,"ERROR",Status,"issue with root file");
close(Sock);
return (-1);
}

Status = setsockopt(Sock, SOL_SOCKET, SL_SO_SECURE_FILES_CERTIFICATE_FILE_NAME,
MQTT_CA_FILE, strlen(MQTT_CA_FILE));

if (Status < 0)
{

close(Sock);
return (Status);
}

Status = setsockopt(Sock, SOL_SOCKET, SL_SO_SECURE_FILES_PRIVATE_KEY_FILE_NAME,
MQTT_PRIVATE_KEY_FILE, strlen(MQTT_PRIVATE_KEY_FILE));

if (Status < 0)
{


close(Sock);
return (Status);
}

lStatus = connect(Sock, (const struct sockaddr *)&LocalAddr,
sizeof(LocalAddr));
if((lStatus < 0 ) && (lStatus != SL_ESECSNOVERIFY))

{
// DBG_MSG("Failed to Connect\r\n");

return 0;
}
DBG_MSG("Connected\r\n");


return SOCKET_CONNECTED;
}

Thanks,

Nagaraj

Hi Nagaraj,

You are accessing to one socket from two different tasks (one task for recv() and one task for send())? Technically this approach is possible, but code need to be very carefully written. Because if error state happens with socket at one task you need deal with this at 2nd task. I remember many related topics at this forum where users failed with this implementation.

Jan

Hi Jan,

          Yes, Same socket used between the recv task and send task.

Thanks,

Nagaraj

Hi Nagaraj,

Do you use battery powered device? If not, maybe you should consider to switch to non-blocking sockets without select() with recv() and send() at one task.

Jan

Hi Jan,

         Device powered from external supply, how can I achieve same functionality without using select() in recv task?

Hi Jan,

         I have a kept device for long run to replicate the issue with switching to non-blocking socket using recv instead of select().

Hi Nagaraj,

Was your issue resolved? Are you still seeing the -452 error and the -100 error or just one of them?

Best regards,

Jesse

Hi Jesse,

           Issue is still persistence.

Thanks,

Nagaraj

Hi Nagaraj,

Error -452 (SL_ESECCLOSED) means that the MQTT broker is terminating the TLS session. Can you get a log from the broker that explains the disconnection?

I also found a similar post:

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/884921/cc3100-getting-sl_esecclosed-error-while-reading-from-secured-socket

where the SL_ESECCLOSED appeared to occur when reading more than 1400 bytes. Do you know if the problem is related to length? Is your buffer aligned with the requested length?

Best regards,

Jesse

Hi Jesse, 

             MQTT broker disconnected with "DUPLICATE_CLIENTID" reason, Whenever we get error from sl_recv we tried to re-connect the device with MQTT broker, "DUPLICATE_CLIENTID" reason indicates when we try to connect again with same clientid without closing the previous MQTT connection from Mqtt broker.

 we are passing 1140 as length to the recv API, But in our Application data will not exceed 1440 length, I think problem is not related to length.

recv(pstHandler->Socket, pstHandler->RxBuffer,
1440, 0);

Thanks,

Nagaraj

Hi Nagaraj,

Is the same ClientID being used by different devices? Each MQTT client must register a unique client ID that will not conflict with other active MQTT client/broker sessions.

Can you get a traffic sniffer log of the disconnection?

Best regards,

Jesse

Hi Jesse,

            No, Unique ClientID is assigned to all the individual device,  if we are connecting again same device with unique ClientID MQTT with out closing the previous connection on -452 error from recv API then well get DUPLICATE_CLIENTID disconnect reason,  I think on -452 error there is no immediate disconnected log observed in MQTT broker untill we re-connected to MQTT broker, I think  on -452 still TCP connection still maintained on between Device and MQTT broker.

Thanks,

Nagaraj

Hi Nagaraj,

In order to debug further, can you provide NWP logs? You can find directions here: Capture NWP Logs

Traffic sniffer logs would be helpful as well.

Best regards,

Jesse

Hi jesse,

              I have configured pin 3 for getting NWP logs but i didn't get any logs, Pin 64 used already in our project. 

MAP_PRCMPeripheralClkEnable(PRCM_UARTA0, PRCM_RUN_MODE_CLK);

MAP_PinTypeUART(PIN_03, PIN_MODE_1);

Thanks,

Nagaraj

Hey Nagaraj,

You should be using pin 62 for the NWP logs according to the User's Guide.

Best regards,

Jesse