TCP connection cannot be established for a long time (about 4.5 hours) through BLE IPv6

[michael lee]

Hi everybody

I use the nrf52 SDK (nrf5_SDK_15.2.0) to develop the IoT application of BLE. The IoT device acts as the TCP server and the BLE gateway acts as the TCP client. The BLE gateway connects the IoT device periodically and disconnects after obtaining datas.

The program of TCP server is modified by the example/IoT/TCP/server in SDK. TCP client is implemented in Linux system with reference to IoT user guide. Different from the above example, link local address is used for IPv6 address, because the connection is only in the local area network.

Occasionally, I find that the gateway and IoT device cannot establish a TCP connection for a long time, and it will recover automatically after about 4.5 hours. By printing log during the period when the connection cannot be established, the BLE connection and IPv6 interface are established normally, but the IoT device has never received IPv6 NS (neighbor solicitation) message from the gateway, untill TCP connection timeout. Further more, the log is printed at the every abnormal returns of the NS message receiving path. It is found that no log is printed during the connection cannot be established. It can be inferred that the SoftDevice does not return any message to the application layer during the connection cannot be established.

The above problem may be improved by adding debug log output in the application layer and slightly changing the processing sequence.

If anyone else has found similar problem and who can tell me how to further investigate or solve this problem.

Best regards!

[Einar Thorsrud]

Hi,

Since no logs are written etc. I assume the expected code is not executing. Could it be that the application is stuck waiting for something that does not happen? Either some very long app_timer timeout, or could it be that the application enters a bad state, and stays that way until something triggers a reset? This is just vague ideas. I suggest you try to debug on the nRF side to see what is actually going on there.

[michael lee]

Hi，Thank you for your reply.

Here have some nRF logs of TCP connection but I don't know if it helps.

First it is normal logs of our TCP connect and disconnect, we can see the ICMP6 NS event clearly. 

Next is the failed logs, we can see that the ICMP6 NS has not been received. The connection timed out 40 seconds after the IPv6 interface was established, and then the BLE connection was disconnected. The process lasted about 4.5 hours.

Finally, the fault is automatically recovered, and the TCP connection can be completed normally again.

In addition, if the log output of BLE IPSP/BLE 6lowpan/lwIP stack driver is enabled, the fault may not be repeated.

[Einar Thorsrud]

Hi,

OK. I am a bit puzzled since this comment made me think the nRF may be in a bad state:

"Further more, the log is printed at the every abnormal returns of the NS message receiving path. It is found that no log is printed during the connection cannot be established. It can be inferred that the SoftDevice does not return any message to the application layer during the connection cannot be established."

But this is actually on the gateway?

Please note that there will be an increase in response time from Nordic employes during the Christmas holiday (starting now), but I will be back in the beginning of January.

[michael lee]

Hi，

OK, I've learned that the response time will be longer during Christmas. I hope there will be some progress after the holiday in January.

[Einar Thorsrud]

Hi,

It looks to me like the nRF is connectable, but the RPi does not connect for some reason. What is the state of the RPi? Do you have logs from there? Since this is where the problem is, I suspect here is where you need to look.