nRFCloud CoAP messages not received

RE: nRFCloud CoAP messages not received

Syed Maysum Abbas Zaidi — Tue, 05 May 2026 13:38:11 GMT

Hi,

Thanks for the update, and that power concern is completely valid. Using confirmable=true is a good next step. It can increase modem on time slightly (waiting for CoAP ACK / retries), so checking power impact on one test device is the right approach.

A modem trace captures low-level modem/network communication, which helps us see where the failure happens. A practical way is to build a trace enabled firmware using snippets and capture with Cellular Monitor or nrfutil trace lte. If the affected unit is deployed and physical/debug access is not possible, that is understandable. In that case, could you try getting the device and reproducing this issue in the lab on a same unit with the same operator, and capture a trace there?

Optional longer-term path: if you already use Memfault (or plan to), it can be used for remote observability and modem trace related workflows in production.

Best Regards,
Syed Maysum

RE: nRFCloud CoAP messages not received

Achim Kraus — Mon, 04 May 2026 09:19:04 GMT

OK, I guess then it's not the case.

-------------------------------------------------------------------

Just, if you curious:

nslookup nrfcloud.com

Name: nrfcloud.com
Address: 3.160.150.112
Name: nrfcloud.com
Address: 3.160.150.106
Name: nrfcloud.com
Address: 3.160.150.87
Name: nrfcloud.com
Address: 3.160.150.5

Using that DNS address resolves in 4 different ip-addresses.

If the device gets one of those 4 at the first time doing a DNS-lookup, it will establish a DTLS session with that. But if on restart a later DNS-lookup results in a different node, even DTLS CID will stop working. Therefore the device needs to stick on restart to the ip-address and must not do a DNS lookup again.

RE: nRFCloud CoAP messages not received

Vincent44 — Mon, 04 May 2026 08:57:47 GMT

I am not sure to fully understand, but I think the answer is no.
My device uses the nRF9160, which is not capable to pause/restore the session with nRFCloud.

RE: nRFCloud CoAP messages not received

Vincent44 — Mon, 04 May 2026 08:56:29 GMT

Thanks for your response.

Trying confirmable=true will off course be my next test.
However, I'll have to check the impact on power consumption: I assume that the modem will be on for a longer period of time, to be able to receive the acknoledge.

The full handshake is performed at every reconnection, and result of is always 0.

I'll what I can do for modem trace. (I am not familliar with this), since the device is currently being used by the customer.

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