multicast only received by CoAP server not client

[ToasTer86]

Hey Nordic devzone,

I am tinkering with the following multiprotocol examples: ble_thread_dyn_mtd_coap_cli (client) ble_thread_dyn_template (server)

Currently the client can be controlled using the BSP buttons or a smartphone with the nordic toolbox apps.

When I press a BSP button 2 on the client a multicast message gets send out to the servers to turn on the light. I have altered the ble_thread_dyn_template to setup a connection with a thingy52, on when it does it sends out a multicast message with the thingy52 MAC address and the IPv6 peer address. Only this message is only captured by all the other servers not the client in this case.

I altered the function :

static void thread_coap_init(void)
{
    thread_coap_configuration_t thread_coap_configuration =
    {
        .coap_server_enabled                = true,
        .coap_client_enabled                = false,
        .coap_cloud_enabled                 = false,
        .configurable_led_blinking_enabled  = false,
    };

    thread_coap_utils_init(&thread_coap_configuration);
}

To set the coap_server_enabled to true, where before the coap_client_enabled was set to true. My application still works the same but the ble_thread_dyn_mtd_coap_cli example is still not picking up my multicast messages.

It most likely has to do with the scope in the function : thread_coap_utils_multicast_light_request_send

switch (scope)
{
case THREAD_COAP_UTILS_MULTICAST_LINK_LOCAL:
    p_scope = "FF02::1";
    break;

case THREAD_COAP_UTILS_MULTICAST_REALM_LOCAL:
    p_scope = "FF03::1";
    break;

default:
    ASSERT(false);
}             

If i check the IPv6 thread addressing site I can see the following multi cast adressing 'domains'

ff02::1	Link-Local	All FTDs and MEDs
ff02::2	Link-Local	All FTDs and Border Routers
ff03::1	Mesh-Local	All FTDs and MEDs
ff03::2	Mesh-Local	All FTDs and Border Routers

Would I need to alter the switch to include any of the other multicast scopes?

Thanks in advance for any tips

[ToasTer86]

Hmm in retro spect I do not think it has to do with the client/server role, but if a node is specified as a end device.

I just ran my ble_thread_dyn_template (server) on all 3 available boards and it seems that the unit that is designated a role 2: end device is not receiving the multicast messages but it is sending the multicast messages.

[ToasTer86]

Is there a way I can force a unit into role 3 as a router, or make sure that my end devices also receive my multicast messages?

[Hung Bui]

@toaster: Are you sure you didn't set the rx-on-when-idle to "disabled" ? If you set that it will acts a sleepy end device and can't receive the packet.

As you already pointed out ff03::1 is mesh local and should be received by all FTDs and MEDs meaning if it's an end device it should receive the packet.

My test here the server with role 2 can receive the packet, turn on/off the light, no problem.

[ToasTer86]

Hey Hung Bui,

Thanks for your reply, they way I have set it is now :

thread_configuration_t thread_configuration =
{
    .role                  = RX_ON_WHEN_IDLE,
    .autocommissioning     = true,
    .poll_period           = 2500,
    .default_child_timeout = 10,
};

Checking the definition that should be a powered device:

typedef enum
{
    RX_ON_WHEN_IDLE = 0,  /**< Powered device */
    RX_OFF_WHEN_IDLE,     /**< Sleepy End Device */
} thread_role_t;

Can I use multicast messages to reach end devices, or should I use unicast messages for that ?

But it would kind of combat the general idea of a mesh network if I would always need to unicast a message to an end node. So shouldn't it be possible to reach endnode's using a multicast message?

If not, what way could I force the client to not take a end-device role?

Thanks again Hung

[Hung Bui]

You would need to double check the log to see if rx-on-when-idle is set to "disabled" or enabled because it maybe saved in flash. I suspect it's a bug that we don't reconfigure thread inside thread_init() in thread_utils.c if the role = RX_ON_WHEN_IDLE.

Please try to do a chip eraseall before testing, and make sure rx-on-when-idle= enable in the RTT log.

ff03::1 should be able to get to all MED devices in the network, you shouldn't need to use unicast address. If you still have trouble, we would need to debug deeper why it didn't receive the message. One easy test you can do is to let it as end device, then kill the leader (and maybe kill other routers also) so that it change to leader/router role and then check if by that change it can receive the multicast packet.