STM32WB OpenThread Coap Multiple Responses

[David Abrahams]

I am attempting to send Multicast Non-Confirmable coap messages to multiple boards, but am only receiving and handling the first response that comes in.

This seems to be supported in the upstream implementation found at https://github.com/openthread/openthread/blob/master/src/core/coap/coap.cpp#L513.

Can you please confirm whether your OpenThread implementation allows receiving multiple responses or if there is a problem with my implementation.

[Remi QUINTIN]

On this point our current OpenThread version is not aligned with the upstream version you are referring to.

So receiving multiple responses when sending Multicast Non-Confirmable CoAP request is not supported.

Our implementation:

   case OT_COAP_TYPE_NON_CONFIRMABLE:

       // Separate response.

       FinalizeCoapTransaction(*message, coapMetadata, &aResponseHeader, &aMessage, &aMessageInfo, OT_ERROR_NONE);

         break;

Upstream implementation you are referring to:

case OT_COAP_TYPE_NON_CONFIRMABLE:

509        // Separate response.

510

511        if (coapMetadata.mDestinationAddress.IsMulticast() && coapMetadata.mResponseHandler != NULL)

512        {

513            // If multicast non-confirmable request, allow multiple responses

514            coapMetadata.mResponseHandler(coapMetadata.mResponseContext, &aMessage, &aMessageInfo, OT_ERROR_NONE);

515        }

516        else

517        {

518            FinalizeCoapTransaction(*request, coapMetadata, &aMessage, &aMessageInfo, OT_ERROR_NONE);

519        }

520

521        break;

[David Abrahams]

I see that your implementation is based on github here:

https://github.com/openthread/openthread/commit/222acd1362af9f5b58bae9d246fe5492c38e7b14

dated 13/9/2018.

The fix is implemented upstream on github here:

https://github.com/openthread/openthread/commit/6a2c3ba10cc66c2939c1b86a78e56ebec882bc4b

dated 10/7/2019.

Do you have any plans to rebase onto a more up to date upstream implementation or to to open source your implementation?

[Remi QUINTIN]

I will push the fix to the development team but I cannot commit about any new rebased version for the short term as I know they have a lot of higher priority developments to complete before.

[JNewe.1]

There are a large number of fixes to this codebase since ST grabbed the source from Github, with some pretty major fixes included.

I would have understood that a rebase would have been critical path for ST considering it would have reasonable affect to anyone trying to use Thread on a STM32WB

This is even more critical since users cannot update the code themselves as the ST implementation is closed source.