CoAP with DTLS on nRF9151

RE: CoAP with DTLS on nRF9151

Tom01 — Tue, 29 Sep 2026 09:03:04 GMT

Yes, go ahead.

RE: CoAP with DTLS on nRF9151

Syed Maysum Abbas Zaidi — Tue, 29 Sep 2026 09:02:06 GMT

Hi,

Great to know that its working without any issue. Is it okay I close this ticket?

Feel free to reach out if anything comes up. Thanks

RE: CoAP with DTLS on nRF9151

Tom01 — Tue, 29 Sep 2026 08:14:16 GMT

Hey Syed,

thanks for checking that out. I've used those PSM and eDRX settings for a couple of days now and there seems to be no issue.

Best,

Tom

RE: CoAP with DTLS on nRF9151

Tom01 — Tue, 29 Sep 2026 08:13:19 GMT

Hey Achim,

thanks for your insights!

We'll keep the socket open for as long as possible then and renew it only if we suspect that it should be renewed.

This would then also make the DTLS session resumption question redundant, as a full reconnect would not occur frequently.

We'll also definitely look into setting up CID properly and keep in mind your suggestion to use multiple DNS addresses. I think we might also try CID with more or less static server instances -if we do actually decide to go with more than one - and a sticky session load balancer. Thingsboard's CoAP transport service is Eclipse Californium based. Good to hear that you've had positive experiences with that.

Best,

Tom

RE: CoAP with DTLS on nRF9151

Achim Kraus — Fri, 25 Sep 2026 17:39:42 GMT

> Do you have any insights and advice on how long the socket could remain open but inactive?

I use PSM and in some cases eDRX. My UDP sockets stay open for days and weeks. They mainly get closed by the modem itself, when that lost the network.

> My understanding is that the CoAP server and especially the load balancer need to be CID aware when multiple server instances are involved.

CID is used to overcome the widely used NATs. The depends a lot on your network setup, but frequently some NATs are on the path, say at the MNO outgress or your cloud ingress. In quite a lot of cases that's even not known. For UDP unfortunately the most NATs uses pretty small timeouts, e.g. 30s or 120s. That means, if your device sleeps (doesn't send a UDP packet), the next UDP packet may show a different public IP address to the server. Usually not bad for UDP, but the DTLS context is related to that address and if that changes, then the server will not be able to find the right DTLS context for that packet.

CID simply replaces the ip-address by a much more stable Connection ID.

Before the CID, one strategy to overcome the address change was to use the (D)TLS session ID to resume a session. That takes less message than a full handshake, but still additional messages.

But "load balancer" is then something, which in many cases stops both, CID and session resumption, because the UDP load balancer will also be affected by the ip-address changes. And the nodes usually don't share the DTLS contexts.

There some ideas to overcome that. One is to use multiple DNS entries and stick after the handshake to the chosen address. An other approach is more complex, "record forwarding" and I only know Eclipse/Californium (I'm one of the developers of that), which comes with such an implementation. And I still don't know, if UDP loadbalancers are out, which would support routing by CID.

(On more interest, you may read some pages at https://github.com/eclipse-californium/californium/wiki)

> What happens to CIDs if for example load balancer or server instances are restarted or scaled down?

Let's focus on the "multiple DNS entries". If a node crashes, it depends on your client to detect that. If the mobile network is healthy and no response nor ack is received, then a new DNS lookup and a new handshake is required. If a "down node" is chosen, the handshake times out and the client needs to check the next addresses.

There are not that many implementations, which offers a DTLS graceful restart, I mainly know Eclipse/Californium. With that, a planed server update usually takes a few seconds. The most device will not recognize that at all and a few ones will need a normal CoAP retry.

RE: CoAP with DTLS on nRF9151

Syed Maysum Abbas Zaidi — Fri, 25 Sep 2026 08:15:26 GMT

Hi Tom,

Regarding your second question there’s seems no conflict between PSM/eDRX and the CoAP client in the SDK.

For client initiated CoAP without observe, that combination is fine in practice. I tried settings close to yours on an nRF9151 and the network accepted PSM/eDRX and confirmable CoAP over DTLS completed normally. So you may run at your end however if anything odd shows up, send logs and we’ll dig in. Thanks

RE: CoAP with DTLS on nRF9151

Tom01 — Fri, 25 Sep 2026 07:45:16 GMT

Hey Achim,

thanks for your responses, this and the previous one.

[quote userid="5203" url="~/f/nordic-q-a/129247/coap-with-dtls-on-nrf9151/571560"]

> Our application will probably have to renew the socket regularly

Why?

[/quote]

It might well be that my understanding of UDP sockets is not correct: Our application will have situations in which the socket will only be used every few hours, potentially even once a day. My assumption so far was that we cannot leave the socket open and inactive for long periods, because the cellular provider might close the session. Though, now that I am thinking about it, this might come down to how PSM and eDRX settings affect the session state. Do you have any insights and advice on how long the socket could remain open but inactive?

[quote userid="5203" url="~/f/nordic-q-a/129247/coap-with-dtls-on-nrf9151/571560"]

> I am not yet sure if we will be able to use CID for session resumptions.

CID is not related to session resumption. CID rather obsoletes session resumption in the most cases.

[/quote]

My wording is probably not correct, because this is the first time that I work with CoAP in-depth. My understanding is that the CoAP server and especially the load balancer need to be CID aware when multiple server instances are involved. I haven't yet checked whether this is possible for us. Maybe you know this better: What happens to CIDs if for example load balancer or server instances are restarted or scaled down?

Best,

Tom

RE: CoAP with DTLS on nRF9151

Achim Kraus — Thu, 24 Sep 2026 18:38:26 GMT

If you provide an ip-capture/wireshark, we will see, what happens exactly.

RE: CoAP with DTLS on nRF9151

Syed Maysum Abbas Zaidi — Thu, 24 Sep 2026 16:24:20 GMT

Hi Tom,

Good to know it worked.

I tested your pattern, TLS_SESSION_CACHE on a new DTLS socket, connect(), then coap_client_req close and repeat. However TLS_DTLS_HANDSHAKE_STATUS was full on two connects, so I did not see session resumption on my test server (not ThingsBoard). The cache option applies to DTLS like HTTPS, but I think resumption depends on the server side so I would suggest you to try on your ThingsBoard.

I am checking details about your second question and will get back to you by tomorrow. Thanks

RE: CoAP with DTLS on nRF9151

Achim Kraus — Thu, 24 Sep 2026 15:13:28 GMT

> Our application will probably have to renew the socket regularly

Why?

> I am not yet sure if we will be able to use CID for session resumptions.

CID is not related to session resumption. CID rather obsoletes session resumption in the most cases.

The nasty point in Nordic's DTLS modem implementation is, that the DTLS state is bound to the socket. If that socket closes, the state is usually gone. I don't know, If there is a way to preserve it, but Nordic will know it.

RE: CoAP with DTLS on nRF9151

Tom01 — Thu, 24 Sep 2026 12:22:38 GMT

Hey Syed,

thanks for the response. I just updated to NCS v3.4.1 and now confirmable requests work! Thanks!

For the record and for the AI: CoAP with DTLS works when the socket is created, socket options for DTLS are applied and the socket is then connected manually. When using the CoAP client API, it is important to then pass NULL as the "addr" argument in the "coap_client_req()" method. This works on NCS v3.4.1.

Furthermore I have two additional questions:

1. Our application will probably have to renew the socket regularly and I am not yet sure if we will be able to use CID for session resumptions. For general TLS session resumption with HTTPS the following seems to work:

int32_t cache_enabled = 1;
err = setsockopt(
    fd, NRF_SOL_SECURE, NRF_SO_SEC_SESSION_CACHE, &cache_enabled, sizeof(cache_enabled));
if (err) {
	printk("Failed to enable TLS session cache, err %d\n", errno);
	return err;
}

Would this also apply to DTLS session resumption in the CoAP case?

2. I was wondering how PSM and eDRX settings affect the inner workings of the CoAP client. We do not plan to use observe functionality. Would settings like

# PSM
CONFIG_LTE_LC_PSM_MODULE=y
CONFIG_LTE_PSM_REQ=y
# PSM Periodic TAU (2 hours)
CONFIG_LTE_PSM_REQ_RPTAU="00100010"
# PSM Active Time (22 seconds)
CONFIG_LTE_PSM_REQ_RAT="00001011"
# eDRX
CONFIG_LTE_LC_EDRX_MODULE=y
CONFIG_LTE_EDRX_REQ=y
# eDRX Cycle: "0000" = 5.12 s, "0010" = 20.48 s
CONFIG_LTE_EDRX_REQ_VALUE_LTE_M="0010"
CONFIG_LTE_EDRX_REQ_VALUE_NBIOT="0010"
# Paging Time Window (PTW): "0011" = 5.12 s for LTE-M / 10.24 s for NB-IoT
CONFIG_LTE_PTW_VALUE_LTE_M="0011"
CONFIG_LTE_PTW_VALUE_NBIOT="0011"

cause conflicts with the timeout and retry behavior of the CoAP client if the modem successfully negotiates them?

Thanks again and best,

Tom

RE: CoAP with DTLS on nRF9151

Syed Maysum Abbas Zaidi — Thu, 24 Sep 2026 08:57:02 GMT

Hi Tom,

Thanks for the detailed CoAP debug log, it matches what we see here.

On nRF9151 with your approach (DTLS, connect(), NULL address to coap_client_req()), we see the same behaviour on NCS v3.4.0 the request and response complete, then sending the empty ACK fails (Error sending a CoAP ACK-message, -106 in the callback). The same application on NCS v3.4.1 works without that error.

Your tests with non-confirmable requests fit this, that path does not hit the same ACK handling. This does not indicate that confirmable CoAP is unsupported on the modem, I think it points to a CoAP client issue on v3.4.0 when acknowledging a confirmable response on a connected DTLS socket. So recommendation is to move to NCS v3.4.1. Do let me know if it runs without error on it.

RE: CoAP with DTLS on nRF9151

Achim Kraus — Thu, 24 Sep 2026 06:24:55 GMT

-106 => #define EAFNOSUPPORT 106 /* Address family not supported by protocol family */

I would check the "dest_addr", "addrlen" parameters.

> I am wondering if the modem rejects that specific message for some reason.

I never recognized that in all the years (sending a couple 10.000 ACKs).

> When using a non-confirmable request, no errors occur. I've confirmed this with GET and POST requests. Data is read from and written to Thingsboard successfully.

That's more a indirect effect. ThingsBoard uses a "Separate Response", a "Piggybacked Response" would work without such an "ACK for Response".

Also not sure, if you want to use observe/notify and therefore the Responses (Notification) may be sent as CON (from time to time to check the interest). In my experience, NATs makes observe/notify pretty frequently useless. We discussed that years ago in the IETF core list.

In the end, if your client is designed for "very low energy consumption", it will frequently sleep for long. Depending on your network setup, that may already cause ip-address changes and usually makes observe/notify not longer working.

RE: CoAP with DTLS on nRF9151

Tom01 — Wed, 23 Sep 2026 13:22:08 GMT

I've found time to trouble-shoot this more and I think the CoAP library debug logs might reveal where the problem lies. With the request set to confirmable, the log seems to show that the request is successfully transmitted, the response successfully received, but the acknowledgement cannot be returned:

[00:00:07.596,099] <inf> coaps: IPv4 Address found 3.127.76.36
[00:00:07.596,405] <inf> coaps: sa_family = 1
[00:00:10.778,137] <dbg> net_coap: coap_client_req: Request is_observe 0
[00:00:10.778,198] <dbg> net_coap: send_request: Send CoAP Request:
                                   REDACTED_TO_HIDE_ACCESS_TOKEN 
[00:00:10.779,632] <inf> main_app: waiting
[00:00:11.101,684] <dbg> net_coap: receive: Receive CoAP Response:
                                   48 45 0c 6e 2b 8a 67 c9  42 04 52 63 c1 32 ff 7b |HE.n+.g. B.Rc.2.{
                                   22 73 68 61 72 65 64 22  3a 7b 22 73 64 6c 43 6f |"shared" :{"sdlCo
                                   6e 66 69 67 54 73 22 3a  36 7d 7d                |nfigTs": 6}}     
[00:00:11.101,715] <dbg> net_coap: recv_response: Received 43 bytes
[00:00:11.101,745] <dbg> net_coap: send_request: Send CoAP Request:
                                   60 00 0c 6e                                      |`..n             
[00:00:11.101,776] <err> net_coap: Error sending a CoAP ACK-message
[00:00:11.101,806] <inf> main_app: Response received with error code: -106
[00:00:11.101,837] <inf> main_app: sleeping
[00:00:11.101,898] <err> net_coap: Error handling response
[00:00:13.669,830] <dbg> net_coap: receive: Receive CoAP Response:
                                   48 45 0c 6e 2b 8a 67 c9  42 04 52 63 c1 32 ff 7b |HE.n+.g. B.Rc.2.{
                                   22 73 68 61 72 65 64 22  3a 7b 22 73 64 6c 43 6f |"shared" :{"sdlCo
                                   6e 66 69 67 54 73 22 3a  36 7d 7d                |nfigTs": 6}}     
[00:00:13.669,860] <dbg> net_coap: recv_response: Received 43 bytes
[00:00:13.669,921] <dbg> net_coap: send_request: Send CoAP Request:
                                   60 00 0c 6e                                      |`..n             
[00:00:13.669,921] <err> net_coap: Error sending a CoAP ACK-message
[00:00:13.669,952] <inf> main_app: Response received with error code: -106
[00:00:13.669,952] <err> net_coap: Error handling response

When using a non-confirmable request, no errors occur. I've confirmed this with GET and POST requests. Data is read from and written to Thingsboard successfully.

After having a look at the library's code where this

static int send_ack(int sock_fd, const struct net_sockaddr *addr, net_socklen_t addrlen,
		    const struct coap_packet *req, uint8_t response_code)
{
	int ret;
	struct coap_packet ack;
	uint8_t ack_buf[COAP_FIXED_HEADER_SIZE + COAP_TOKEN_MAX_LEN];

	ret = coap_ack_init(&ack, req, ack_buf, sizeof(ack_buf), response_code);
	if (ret < 0) {
		LOG_ERR("Failed to initialize CoAP ACK-message");
		return ret;
	}

	ret = send_request(sock_fd, ack.data, ack.offset, 0, addr, addrlen);
	if (ret < 0) {
		LOG_ERR("Error sending a CoAP ACK-message");
		return ret;
	}

	return 0;
}

seems to produce the error message, because this

static int send_request(int sock, const void *buf, size_t len, int flags,
			const struct net_sockaddr *dest_addr, net_socklen_t addrlen)
{
	int ret;

	LOG_HEXDUMP_DBG(buf, len, "Send CoAP Request:");
	if (addrlen == 0) {
		ret = zsock_sendto(sock, buf, len, flags, NULL, 0);
	} else {
		ret = zsock_sendto(sock, buf, len, flags, dest_addr, addrlen);
	}

	return ret >= 0 ? ret : -errno;
}

throws the error when trying to write the ACK ("60 00 0c 6e") to the socket, I am wondering if the modem rejects that specific message for some reason. I think that this is not a general socket issue, because I can reuse the socket for multiple following requests successfully. It just seems to reject only the ACK.

Do you have an idea why this happens? Are confirmable packets not supported via the modem?

RE: CoAP with DTLS on nRF9151

Tom01 — Wed, 23 Sep 2026 09:55:42 GMT

Hi Syed,

thanks for trying out the sample! I'm using modem firmware v2.0.4.

One more thing that might cause the 106 errors inside the callback, is the path length of the request. Because of the API structure and the access token, the path is 62 characters long in this particular case. I'm not sure if this might be an issue, but just for the sake of completeness, here are the CoAP settings I use:

CONFIG_COAP=y
CONFIG_COAP_CLIENT=y
CONFIG_COAP_CLIENT_THREAD_PRIORITY=10
CONFIG_COAP_CLIENT_MESSAGE_SIZE=512
CONFIG_COAP_CLIENT_MESSAGE_HEADER_SIZE=128
CONFIG_COAP_CLIENT_MAX_PATH_LENGTH=128

Best,

Tom

RE: CoAP with DTLS on nRF9151

Syed Maysum Abbas Zaidi — Wed, 23 Sep 2026 09:43:08 GMT

Hi,

Thanks for reaching out.

I am trying out on my end and will get back to you soon. Although not very important, can you share the modem firmware version you are using?

Best Regards,
Syed Maysum