CC3120: SSL Read Errors and TCP Keep-Alive Timeout Issues with CC3120

Hi,

TCP in general is not related to routers/APs since these are handling only up to layer 3 in OSI model.

TCP is layer 4 so it is handled on the network stacks of the two peers connected to each other (CC3120 and the TCP server).

TCP keepalive is used to keep the TCP connection alive and ready and it really depends on the server if it "disconnects" the peer upon no data.

So it may be that the server you are using kick the peer devices on less than 5 minutes but it is really a server implementation and not related to the routers or the CC3120.

Not sure what you mean by Wi-Fi interrupts which are only used to signal the host application that there is data/event pending for it.

Regards,

Shlomi

Hi,

We have observed that with certain ISPs, our TCP connections remain active even with a 5-minute TCP KeepAlive interval, while with others, disconnections occur. Could this behavior be influenced by the ISP?

Additionally, we are encountering an issue where our WiFi chip generates an interrupt, and upon attempting to read data, we receive an SSL READ ERROR. Does the CC3120 generate any interrupt if the host/server disconnects after a period of inactivity? We only receive immediate interrupts for AP disconnections, but not for host disconnections.

Your assistance in understanding these behaviors would be greatly appreciated.

Thank you.

Hi.

We have observed that with certain ISPs, our TCP connections remain active even with a 5-minute TCP KeepAlive interval, while with others, disconnections occur. Could this behavior be influenced by the ISP?

Additionally, we are encountering an issue where our WiFi chip generates an interrupt, and upon attempting to read data, we receive an SSL READ ERROR. Does the CC3120 generate any interrupt if the host/server disconnects after a period of inactivity? We only receive immediate interrupts for AP disconnections, but not for host disconnections.

Is there any specific reason or configuration that could cause the SSL_READ_ERROR? Why does this issue occur only with certain internet connections and not in all scenarios? Do you have any recommendations for ensuring a stable connection?

Your assistance in understanding these behaviors would be greatly appreciated.

Thank you.

Hi,

There is no SSL_READ_ERROR event. What do you get exactly?

Basically, you should have on application a general CB for socket related errors, SimpleLinkSockEventHandler.

I don't see how an ISP can influence on TCP keepalive as it is mainly related to the TCP server itself regardless of the internet provider.

Regards,

Shlomi

Hi Shlomi

Thanks for the response.

We are using the definition for the _i16 sl_Recv function from the provided link.SimpleLink CC3120/CC3220 Host Driver: Socket. 

Whenever we receive a zero from this function, we encounter a disconnection issue. Could you please help us understand the possible reasons behind this? 

Hi,

I agree with Shlomi and what he wrote.

Best way to move forward is to capture network traffic by sniffer like a Wireshark or tcpdump. Please set filter to capture communication between your server and CC3120 device only. After providing .pcap file that we can talk what is going on. Without log from network sniffer it is just about guessing.

Jan

and just to complete, getting 0 on sl_Recv() means the other side closed the connection (so on a sniffer you would see a TCP FIN from the server to the client).

Shlomi

Hi Shlomi.

I am trying to sniff the data. before this, I have few questions like

1. How TCP keep-alive failures are handled. Specifically, I would like to understand the mechanism used by the CC3120 to detect and manage TCP keep-alive failures. For example, in the RS9116 chip, TCP keep-alive failures are indicated by specific error codes, and the socket is closed upon detection of a failure. Could you provide detailed information on the equivalent process for the CC3120, including any relevant error codes, events, and recommended handling procedures?

2. Additionally, are there any specific timeout settings that should be configured on the CC3120 to ensure reliable TCP keep-alive functionality? If so, could you provide guidance on how to configure these settings? Because for RS9116 chip, the SI labs informed us to use TCP keep alive timeout as 3mins, but in CC3120 we are using 5mins. 

Hi,

You can "play" with the keepalive via an API.

_i16 Status;
_u32 TimeOut = 180; /for example every 3 minutes
Status = sl_SetSockOpt(Sd, SL_SOL_SOCKET, SL_SO_KEEPALIVETIME,( _u8*) &TimeOut, sizeof(TimeOut));
if( Status )
{
// error
}

As for the keepalive, there is no event as far as I remember. If the other side does not respond to the keepalive, most likely the socket gets closed internally but I need to check if this is the case.

Regards,

Shlomi

Hi Shlomi,

I have sniffed the Wi-Fi Data during the Disconnection, But there No TCP FIN or RST from the server. 

Is this typically indicating a silent TCP connection drop by the router or NAT device. The router removes the NAT mapping for the TCP session due to inactivity or timeout but does not send any FIN or RST. Is the device believing the socket is still valid, but on the next attempt to send data, the TCP stack detects the failure and triggers a socket event. Is this the reason could be for the Socket trigger event? 

I initially suspected that the Router would send any signal or trigger the CC3120. But the CC3120's internal TCP stack detects the failure only when the host tries to use the socket. This is a local detection of a broken connection, not an externally triggered event. Is this right?

This is possible if the TCP connection is dropped without sending any TCP FIN.

This way, the SL is unaware that the TCP connection was dropped.

Hi Shlomi,

If a router silently removes the NAT mapping for TCP session (due to inactivity or table exhaustion) and does not send a TCP RST or FIN, how does the CC3120's network detect this condition and respond - particularly when the host MCU is in Sleep mode?

Can you explain the process by which the SimpleLink network processor triggers the socket event upon the detecting a transmission failure, and how this event is communicated to the application?

If the TCP is silently dropped, the only way to detect it is by sending a keep alive.

The purpose of the keep alive is to detect broken or lingering connections.

The other way is when the device is actively sending or receiving.

if it tries to receive, most likely it would get 0 which means the other side is not there.

As for sending, I am not sure since I have not tested it.

Shlomi

Hi Shlomi,

Last question, if the router deletes the NAT mapping for TCP session due to inactivity, will the CC3120 detect the failure and trigger a socket event while the host MCU is still sleep?

Hi,

There is no way of the NWP to know it since it was silently removed.

If at any point an event comes and the host is asleep, it would be woken up and you should see the event.

Shlomi 

Thanks, 

I have a follow up question:

If TCP keep-alive is enabled and NAT mapping is lost silently, will the NWP eventually detect the failure due to missed ACKs (from the keep-alive probes)?

• In that case, will it generate a socket close/error event?
• And if the socket trigger event is configured, will that wake the Host MCU even though the peer never sent a FIN or RST?

Just trying to confirm whether keep alive failure alone is enough to trigger wake up from sleep?

If not, what would be the reason for the Socket trigger event from the Wi-Fi Chip when the NAT mapping is lost while the Host MCU is at sleep? 

Hi,

At least from I am seeing in the code, upon keepalive exhausting all the retries, the socket connection would get reset, which is exactly as if you would close the socket yourself.

Having said that, I do not see any unsolicited event fired to the host.

So the host in this case would not know until it tries to receive from the socket (and should get 0) or send.

Regards,

Shlomi 

Hi 

But the TI documents says that in Low Power Deep sleep NWP remains active, and socket trigger can be configured to wake the MCU. 

Also, it says Network processor in CC3120/CC3200 handles all the Wi-Fi and TCP/IP stack operations indecently of the host MCU. Means It will handle the TCP sessions and Keep-alive Management. All continue running even if the Host MCU enter sleep (like LPDS Mode). 

These are the Scenario:

1.  A TCP socket is established through a NAT enabled router
2. TCP Keep alive is enabled using SL_SO_KEEPALIVE
3. The Host MCU Low power Deep Sleep Mode
4. After some time, router silently removes the NTA mapping due to inactivity (No FIN or RST).
5. The peer server does not receive the keep alive probes.

Our understanding is:

1. If the router got the silent breakdown, The CC3120 is unaware that the NAT mapping has expired because no explicit TCP-layer event (like FIN or RST) is received from the NAT device or server.
2. The CC3120 continues to believe the TCP connection is active.
3. The CC3120 will continue to send TCP Keep-Alive probes (if configured) via its Network Processor (NWP).
4. When the NAT mapping has expired, these Keep-Alive probes will fail to reach the server because the NAT device no longer routes packets for the connection.
5. If the Keep-alive probes go unanswered, NWP will internally close the TCP socket and Will generate an async socket event on the socket closure.
6. This event is waking the Host MCU from sleep and allowing to handle reconnection. 
7. Thats how i am getting a Socket trigger event when i am manually trying to reproduce the Closure of TCP session. When TCP session is closed by the Router, MCU is in still sleep Mode, within 5mins (i.e TCP Keep alive timeout), I am receiving a socket trigger event from Wi-Fi chip.  

Questions:

1. Is it correct that the NWP handles the TCP keep alive retries independtly during LPDS as mentioned in the TI documents and e2e Forms? :https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/400040/cc3200-tcp-socket-keep-alive 
2. TI document: https://file.elecfans.com/web1/M00/00/06/o4YBAFnLj_GAcI77AAJsXLcKik8347.pdf?utm_source=chatgpt.com

Need a confirmation on this. so, i will be clear and be able close this. 

Thanks

Hi,

Yes, this is how it should behave.

The NWP is in different power mode than the host which may sleep until the NWP wakes it for packets.

What I didn't see and maybe missed is that upon keepalive expiration, the NWP wakes up the host with an event indicating it.

But I understand you tested it and you can see that the host is awake after 5 minutes when keepalive is expired. Is that true?

Regards,

Shlomi

Yes Shlomi. 

Thats true. When I am manually trying to reproduce the TCP session expiration from router side, within 5minutes, i could be able to see that the Host is awake when TCP keep alive expires. 

this is great, thanks for validating.

so your understanding is correct.

Shlomi