RE: nRFCloud CoAP messages not received

Achim Kraus — Thu, 30 Apr 2026 16:39:50 GMT

Do you use DTLS 1.2 CID and save/restore the session for cfun=0/cfun=1?

Then such pretty high loss rates are sometimes caused by a DNS-load-balancer.

On the initial exchange a DTLS session is only established on one node. That's fine, as long as the ip-address is used.

But it may fail, if a follow-up DNS lookup results in the ip-address of an other node.

RE: nRFCloud CoAP messages not received

Syed Maysum Abbas Zaidi — Wed, 29 Apr 2026 15:34:14 GMT

Hi,

Thanks for the clear description and the plot. I think the good RSRP and connection evaluation values alongside missing messages in nRF Cloud usually means we should look beyond the bad signal alone. You mentioned that you are using non-confirmable CoAP and there is no ACK from the server, so in this case the stack has no way to know if the message was received. A return value of 0 from nrf_cloud_coap_json_message_send only means the UDP packet left the device stack, not that nRF Cloud received or stored it. So could you try to switch to confirmable CoAP (confirmable=true) on the test device? and check the return values.

Also, since the modem is powered off after each cycle, a full DTLS handshake and reauthentication with nRF Cloud is usually required on every reconnect. Could you also log the return value of nrf_cloud_coap_connect() each cycle to confirm it always succeeds before the send?

Can you provide a modem trace on an affected device during a failed send cycle? As this will help us to see whether the DTLS handshake, PDN attach, or UDP transmission is failing at the network level. Thanks

Best Regards,
Syed Maysum