Losing connection with Thread CoAP Google Cloud example

[thread_yoda]

Dear Nordic Support Team,

I haven't seen any forum posts directly applicable to the issue I'm seeing so I hope you can point me in the right direction.

The basic Thread CoAP Google Cloud example has been working fine, but I noticed a couple of peculiarities. I'm a still using the Thread SDK v4.0.0 as I didn't see there were specific items in the 4.1.0 SDK release to address any of these issues. 

1) The first issue is that when I leave the network on for some period of time, it seems to not be able to send DTLS application data packets anymore. For example, I would press the buttons to try and increment or decrement the count, but I only see MAC level exchanges. I can see from the sniffer that there are no "DTLS Application Data" exchanges. 

In order to reconnect I have to power cycle the Thread FTD. It then re-establishes the DTLS connection, then everything is back to normal. How I can I avoid having to do this periodically?

2) The second issue is that the network does not seem to recover from a power cycle of the border router. This happens when I have the network unplugged for quite some time. My expectation is that the network should resume from where it left off, but that has not been my experience. I have to re-form the border router using the OTBR web interface, then do a re-flash of the FTD to let it join again. At this point, the network is back and works as per normal.

How can I solve these two issues.

Thanks for your help in advance.

[Jørgen Holmefjord]

Hi,

Our Thread developers have reproduced this behavior. After about 30 seconds of inactivity/no data sent from the device to the cloud, it seems that the cloud does not respond to the data anymore. We suspect that this is related to some sort of timeout in the Google Cloud CoAP proxy, which closes the connection without generating a DTLS Close message. We have not yet found the exact config that causes this behavior, but the CoAP proxy code and config files are available here. 

I will try to look more into this today and tomorrow, and get back to you if I find some configuration that prevents this from happening.

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

Sorry for the slow progress on this issue. I had some troubles with setup and reproduction due to some firewall problem. I now have it setup and can consistently reproduce the behavior you are describing. I still have not found the root cause of the dropped DTLS session, but I have confirmed that this is the problem from the Google Cloud Logs:

I will get back to you when I have more details.

Best regards,
Jørgen

[thread_yoda]

Hi Jørgen, 

No worries! Thanks for the last couple of updates and for working to reproduce the problem consistently. So one thing that I did do is decrease the timeout interval in the sample application for temperature measurement to 1 second. I thought that this would keep the connection open but you still see the same behavior. 

Thanks in advance for continuing to poke at this.

[thread_yoda]

I seem to be having more luck with using this setting for the memory block size in the sdk_config.h: 

#ifndef MEMORY_MANAGER_XLARGE_BLOCK_SIZE
#define MEMORY_MANAGER_XLARGE_BLOCK_SIZE 3100
#endif

A slight bump over the original number.

[thread_yoda]

Darn. A few hours later after writing that it stopped working again.