Problems on nrf52840 coap server to receive packages

[taoyinzhou]

Hi All, 

I want to implement a function to send data from the internet coap client to nrf52840 DK coap server. The nrf52840 runs .hex file which is one modified from Nordic Thread SDK example\thread\simple_coap_server, but I find that whether I use the otCoapAddResource registered function or the coap_default_handler function, neither received the coap data that internet coap client sent. I've caught coap message on the wpan0 interface of OTBR, but the function didn't work as if it hadn't received those package, that is the OTBR in wpan0 has received this package, but it doesn't deliver to nrf52840 DK coap sever. 

Therefore, how do I get the nrf52840 DK coap server to receive and process packages from coap client successfully?

I really appreciate any help you can provide. 

Best, 

Tao

[Jørgen Holmefjord]

Hi,

Can you provide more details about the "internet coap client"? How are the packets addressed to the CoAP server node in the Thread network? Do you have global IPv6 connectivity to the border router?

Can you post logs, packet captures, etc that can help with identifying where the packets stop? If you could also upload the modified CoAP server project to show the changes you made, that would also be helpful.

Best regards,
Jørgen

[Jørgen Holmefjord]

It looks from your sniffer logs that you do not have global IPv6 connectivity and/or the CoAP cloud server is running on a IPv4 interface. In order to send packets from IPv4 cloud service to the nodes in the network, you either need to use global IPv6 addresses (2000::/3 prefix), or you need to setup a translation method on the border router to forward the packets to the correct node (for instance NAT46). The border router image provided by Nordic only enables NAT64, which can send packets from the IPv6 based Thread network, to global IPv4 internet. It does not provide any mechanisms for packets going from global IPv4 internet to the IPv6 based Thread network.

[Jørgen Holmefjord]

Sorry, you are right. It is possible for NAT64 to receive packets if it has the state from a recent transfer, or it is using static routing.

Have you tried removing the first backslash from the URI path? As you can see from the proceeding resource definitions, the leading backslash is not used in the path, this is added automatically by the CoAP libraries:

.mUriPath = "$sys/CxD2hb4NHT/tttt/thing/property/set",

[taoyinzhou]

I've tried it, but it still doesn't work.

[Jørgen Holmefjord]

Do you have any log outputs from your application?

Are you receiving any events in coap_default_handler() (or some other CoAP handler) when the message is received?

[taoyinzhou]

coap_default_handler()  or other coap handle have no received any events when the message is received.

Where do I add the print log?

[Jørgen Holmefjord]

I believe that logging should be enabled by default in this example, over RTT. You can use J-Link RTT Viewer to see the logs.

You can increase the log-level output from application by setting this config to Debug/4 in your sdk_config.h file:

// <o> NRF_LOG_DEFAULT_LEVEL  - Default Severity level
 
// <0=> Off 
// <1=> Error 
// <2=> Warning 
// <3=> Info 
// <4=> Debug 

#ifndef NRF_LOG_DEFAULT_LEVEL
#define NRF_LOG_DEFAULT_LEVEL 4
#endif

For more details about logging from OpenThread stack, see OpenThread logging.

[taoyinzhou]

I tried to set the Log level to 4 as you said, and then checked with debug in SEGGER Embedded Studio, but I only saw the print Added by myself, without any other log.

[Jørgen Holmefjord]

Yes, logs from OpenThread are set to OT_LOG_LEVEL_CRIT by default. If you want to increase this level, you can do that as described in the link I provided above. Then you need to rebuild the OpenThread libraries.