• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 39 subscribers
  • Views 134 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3220SF: WiFi connection instability

Nelson Capela
Prodigy 70 points
Part Number: CC3220SF

Hello, 

Currently we are facing some problems on the Wi-Fi connection stability: it disconnects and connects several times during the day. 

(this capture in on 137 end-point)

We can observe here two situations: 

  1. It looks like that 239 end-point does not receive nothing during 5 minutes and the it triggers the keep-alive message
  2. 239 end-point sends a TCP Window Update but, since it does not receive nothing during 60s, it triggers the FIN
    1. 137 end-point is answering to the TCP Window Update but already after the FIN
  • Do you see that we should decrease SL_SO_KEEPALIVETIME to 4 minutes in 239 end-point side? currently it is 5 on both
  • Should we increase this 60s timeout? If so, how can we increase it? 

Thank you.

  • 0
    TI__Guru 56345 points

    Hi,

    I assume this comes from a customer site. Roger Monk already pinged me yesterday about this one. Do we have the option to capture air sniffer or fetch an NWP logger?

    regarding the setup, is .137 a TCP server and .239 is the CC3220SF device (as client)?

    if so, .239 does seem to not answer but the question is where it is stuck. may be that the AP buffers the packets and CC3220 does not poll, or the CC3220 polls but doesn't send the response back or even that it sends the response but the AP doesn't pass it through. an air sniffer would help a lot. If you do not have the option, I would start by just adding another stream to see that the IP layer is working. it is preferred to have another TCP/UDP but even a ping is OK at this point. If the ping is working while the socket is lingering, then at least we know that the AP behaves OK and it might be a firewall kind of issue (I understand that the AP is in router mode).

    Increasing the keepalive or the timeout is not possible and I don't think it would help here. Regarding the 60sec timeout, seems to me that the server side is not responding to the TCP window update at all (not sure why you said it responds after the FIN).

    Regards,

    Shlomi

  • 0 in reply to Shlomi Itzhak
    Prodigy 70 points

    Hello Shlomi,

    Your assumptions are right.

    For us, it is hard to have that captures and even the introduction of the traffic since we do not have access to the environment where our device is. 

    We have identified the possibility of change the keepalive timeout using sl_SetSockOpt with SL_SO_KEEPALIVETIME, but we still did not tried; however, we know that this will only minimize the impact.

    We will try to see the possibility to connect our device using other router or using an hotspot. 

  • 0 in reply to Nelson Capela
    TI__Guru 56345 points

    Thanks, would be great if we can narrow it down to what makes it happen and at what conditions.

    I would also test if ping goes through during the "no service" period.

    shlomi