CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

gc0rreiab — Thu, 26 Feb 2026 16:48:04 GMT

Given that the OT-CLI sample uses direct IEEE 802.15.4 radio integration with the OpenThread stack, would you still recommend using the Zephyr CoAP API instead of following the OT-CLI implementation approach?

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

Benjamin — Tue, 24 Feb 2026 11:59:43 GMT

I need to correct myself. The default architecture in the CLI sample is the direct IEEE 802.15.4 radio integration with the OpenThread Stack, not the integration with Zephyr networking layer (L2).

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

gc0rreiab — Fri, 20 Feb 2026 19:53:03 GMT

Hi,

Thank you for the effort and guidance — I really appreciate it. I’ll test this on my side and provide feedback shortly.

Regarding your suggestion to use the Zephyr CoAP API, do you foresee any issues with combining the Zephyr CoAP API (using OpenThread as the transport layer) with direct OpenThread API calls?

In my application, I infer the location of SED devices based on their parent router’s MAC address and cross-reference this information with a LUT that maps all Thread Router devices, their MAC addresses, and their physical locations. Consequently, one of the data fields included in the large payload (up to 2500 bytes) that the SED needs to transmit to the CoAP server via block-wise transfer is the MAC address of its OpenThread parent router, which I obtain through direct OpenThread API calls.

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

Benjamin — Fri, 20 Feb 2026 15:34:30 GMT

Hi,

I reproduced your issue with block-wise transfers and confirmed that the block count parameter was being treated as the payload.

When building the sample, you are using the prebuilt OpenThread library, so the configuration changes are not applied. Block-wise CoAP is not enabled by default so it fails.

To fix this:

Enable block-wise CoAP support:
CONFIG_OPENTHREAD_COAP_BLOCK=y

This maps to:
OPENTHREAD_CONFIG_COAP_BLOCKWISE_TRANSFER_ENABLE

Force OpenThread to rebuild by enabling:
CONFIG_OPENTHREAD_SOURCES=y

After enabling both options and rebuilding, block-wise transfers work correctly. I was able to send a request successfully using:

ot coap post <synthesized IPv6 address> <uri> block-64 8

For the last question. You should rely on the Zephyr CoAP API as described in these docs, this requires no changes as this is the default. The docs also describes the pros and cons of each approach.

Best regards,
Benjamin

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

gc0rreiab — Fri, 20 Feb 2026 12:02:30 GMT

Hi Benjamin,

Are there any updates on this? I’m still unable to determine whether it’s possible to test CoAP Block-Wise transfers over OpenThread using the ot-cli sample or directly through the OpenThread APIs in the nRF Connect SDK.

Even after enabling the relevant Kconfig parameters, the feature does not work as expected:

# Enable OpenThread
CONFIG_OPENTHREAD=y
# Enable OpenThread features 
CONFIG_OPENTHREAD_NORDIC_LIBRARY_MASTER=y
CONFIG_OPENTHREAD_COAP_BLOCK=y

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

Benjamin — Mon, 16 Feb 2026 08:56:35 GMT

Hi,

Thank you for your response and for your patience. We have not had the opportunity to review your ticket yet, but we hope to provide an update before the end of the week.

Best regards,
Benjamin

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

gc0rreiab — Tue, 10 Feb 2026 10:48:10 GMT

Sorry for the late response. Regarding the specific Border Router I’m currently using, I’m running a prebuilt Docker container with a working Border Router from the official page on an RPi CM4 + nRF52840 Dongle. As far as I understand, each CoAP Block-Wise transfer is treated as an independent CoAP message. Therefore, if all normal CoAP messages transmitted by my SED device are reaching the CoAP server, I assume the issue is not related to the OTBR. Have you already run any tests on your side?

Another question you have been ignored in my different post: I need to send CoAP payloads larger than 2.5 KB over OpenThread (nRF54L15DK) and noticed that both the Zephyr CoAP API and the OpenThread CoAP API support block-wise transfers. For this use case, which should be preferred? Should I use the Zephyr CoAP API or rely directly on the OpenThread CoAP API for block-wise payloads over OpenThread, and what are the main pros and cons of each approach?

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

Benjamin — Wed, 14 Jan 2026 14:59:40 GMT

Hi,

I have not tested it yet, but I will try to reproduce.

What are you using as your Border Router?
Could you share your build log and the exact shell commands you run, step by step?

If available, an 802.15.4 sniffer trace would also be very helpful.

Regards,
Benjamin

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

gc0rreiab — Tue, 13 Jan 2026 18:00:09 GMT

I’ve added the suggested configuration to my prj.conf, but the behavior of the ot-cli sample when using the block-wise command remains the same.

#
# Copyright (c) 2020 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# Enable OpenThread
CONFIG_OPENTHREAD=y
# Enable OpenThread features 
CONFIG_OPENTHREAD_NORDIC_LIBRARY_MASTER=y
CONFIG_OPENTHREAD_COAP_BLOCK=y

# Network shell
CONFIG_SHELL=y
CONFIG_OPENTHREAD_SHELL=y
CONFIG_SHELL_ARGC_MAX=26
CONFIG_SHELL_CMD_BUFF_SIZE=2510
CONFIG_GPIO_SHELL=y

# Increase Settings storage size
CONFIG_PM_PARTITION_SIZE_SETTINGS_STORAGE=0x8000

Below are the steps I’m following.

1. From the ot-cli sample (running on the nRF54L15 DK), obtain the synthesized IPv6 address:

uart:~$  ot dns resolve4 coap.me
DNS response for coap.me. - fd84:eb3c:3ceb:2:0:0:8666:da12 TTL:300 
Done

2. Send a block-wise CoAP request:

uart:~$ ot coap post fd84:eb3c:3ceb:2:0:0:8666:da12 large-create block-64 20
Done

Based on the coap.me web interface, the server appears to receive only the value 20, rather than 20 blocks of random data as described in the documentation.

Have you tested this on your side? How can block-wise transfer be enabled in the ot-cli sample?

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

Benjamin — Tue, 13 Jan 2026 09:21:25 GMT

Hi,

You do not set OPENTHREAD_CONFIG_COAP_BLOCKWISE_TRANSFER_ENABLE directly in your prj.conf as this is not a Kconfig symbol. It is part of OpenThread’s CMake feature flags.

Try setting CONFIG_OPENTHREAD_COAP_BLOCK=y instead.

Regards,
Benjamin

RE: CoAP Block-wise Transfer over OpenThread (tested via OT-CLI)

Achim Kraus — Sun, 11 Jan 2026 07:48:47 GMT

Not as answer to you question, more a general note on blockwise (with a decade of experience ;-) ):

Using PUT blockwise comes with the challenge, that in case of failures it's not clear how to recover and usually requires a "full retry".

Exchanging the roles (usually easy with CoAP though all messages share the same basic structure, regardless or request or response) enables in common cases to use a GET blockwise, which is much easier to recover from failures, as long as the resources to read is "stable enough".