CoAP with DTLS on nRF9151

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