This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Openthread SED multicast

Hi Nordic team,

Experimenting with nRF NCS v1.5.0, Openthread CoAP.

When the client send a message to server, CONFIG_OPENTHREAD_MTD_SED is enabled, I reduced the poll period to 5 seconds, and I can see the SED node checking in every 5s (Data request).

When I send a multicast message from CoAP clientto ff03::1, the MTD in SED does not receive the message. when not in SED, it receives the message as expected.

From the OT spec it seems like the router should buffer messages sent when SED was sleeping, and forward to it when it wakes up, i.e. when "Data Request" happens.

Did I misinterpret the spec? or is there something else going on?

Here's the wireshark capture of packets sent, node MAC ending in :cd96 is the client sending the light request. 0x4c01 is checking in with the route 0x4c00 and receives ACK back but no further data is forwarded to it. I attached the wireshark log as well.

OT_CoAP_Client_Server_SED_deosnt_rx_data.pcapng

2nd question is about  otThreadSetLinkMode(), it return 7 sometimes, which prints "Failed to set MLE link mode configuration" i.e. E2BIG 7 /* Arg list too long */.

Since I don't have access to source, (or do i?) can you please explain why this happens?
Arguments are simply 2 as per sample function 

toggle_minimal_sleepy_end_device()

 otThreadSetLinkMode(context->instance, mode); mode was retrieved earlier otThreadGetLinkMode(). 

I am having a hard time replicating this issue, but when it happened a reset didn't fix it, i had to erase the chip and reporgam (as suggested in another post)

seems like Mode input argument has changed from 4 members (ncs 1.3.x)  to 3 (ncs 1.5.x) ... hmm perhaps that's the issue?

in modules/lib/openthread/include/openthread/thread.h  i don't have "secureDataRequests" under mode struct:

typedef struct otLinkModeConfig
{
    bool mRxOnWhenIdle : 1; ///< 1, if the sender has its receiver on when not transmitting. 0, otherwise.
    bool mDeviceType : 1;   ///< 1, if the sender is an FTD. 0, otherwise.
    bool mNetworkData : 1;  ///< 1, if the sender requires the full Network Data. 0, otherwise.
} otLinkModeConfig;

3rd question:

I need CoAP Server and Client both in one node, since each nRF52840 in our architecture could be an initiator of a command to another resource, and simultaneously it has resources itself.

Therefore i needed to combine samples of OpenThread/coap client and coap server, which as I understand use different underlying coap implementations, Zephyr coap vs. OT coap.
Seems to work fine other than the 2 issue above, but perhaps this is the cause of the issue #1? Is nordic going to port over the OT Coap Server sample to use the recommended Zephyr Coap library soon?

Thanks,
Farhang

Parents
  • Hello Farhang, 

    I needed to confer with our OpenThread experts.

    Question 1 - SEDs do no receive the ff03::1 multicast messages by design. There are different multicast addresses that are used by SEDs. From Thread 1.1 Spec - Chapter 5.2.3.2:

     

    You should be able to use the following addresses:

    ff33:40:fde2:3960:66dd::1
    ff32:40:fde2:3960:66dd::1
    
    
    

    These are Link-Local All Thread Nodes and Mesh-Local All Thread Nodes addresses. For more information, please see RFC3306 - Unicast-Prefix-based IPv6 Multicast Addresses.

    Question 2 - If the board board was programmed from FTD to MTD FW and the persistent storage has not been cleared, you may observe issues similar to that. Then flashing the device, make sure to use:

    west flash --erase

    Question 3 - The Zephyr CoAP API implementation is simpler than OpenThread. In Zephyr's case the CoAP implementation will prepare the frame, but you will need to send it yourself. Also retransmissions are not handled automatically. There are plans to port the CoAP server, however, I have no timeline for this I'm afraid.

    Please note that the following days are Easter holidays in Norway and one must expect a delayed answer due to short staff in the Technical Support team.

    Kind regards,
    Øyvind

Reply
  • Hello Farhang, 

    I needed to confer with our OpenThread experts.

    Question 1 - SEDs do no receive the ff03::1 multicast messages by design. There are different multicast addresses that are used by SEDs. From Thread 1.1 Spec - Chapter 5.2.3.2:

     

    You should be able to use the following addresses:

    ff33:40:fde2:3960:66dd::1
    ff32:40:fde2:3960:66dd::1
    
    
    

    These are Link-Local All Thread Nodes and Mesh-Local All Thread Nodes addresses. For more information, please see RFC3306 - Unicast-Prefix-based IPv6 Multicast Addresses.

    Question 2 - If the board board was programmed from FTD to MTD FW and the persistent storage has not been cleared, you may observe issues similar to that. Then flashing the device, make sure to use:

    west flash --erase

    Question 3 - The Zephyr CoAP API implementation is simpler than OpenThread. In Zephyr's case the CoAP implementation will prepare the frame, but you will need to send it yourself. Also retransmissions are not handled automatically. There are plans to port the CoAP server, however, I have no timeline for this I'm afraid.

    Please note that the following days are Easter holidays in Norway and one must expect a delayed answer due to short staff in the Technical Support team.

    Kind regards,
    Øyvind

Children
No Data
Related