[OOB 5.6 r2] the default address (ff03::1) cannot work for multicast

[soramame21]

I found the default address (ff03::1) is not for multicast. but the address (ff02::1) works well for multicast.
When making a socket with ff03::1, message could be sent for each button press, but no message could be received on the board sent the message, neither other boards connected locally.
Once I changed the address to ff02::1, the board sending message and other local boards can receive the message to turn on/off LED.
my test environment :

• boarder router: K64F with Atmel RF233 (2.4G)

• LOWPAN_ROUTER: NUCLEO_F401RE with Atmel RF233 (2.4G) x 2

• 6LoWPAN-ND, with no Thread

• Since LED cannot be used on this board, there is a pin collision D13 between LED and SPI_SCK, I removed led on/off operation but kept LED turn on/off print.

• tested on following 2 boarder router firmware versions. ff03::1 doesn't work on both conditions, but ff02::1 works well on both of them.

"backhaul-dynamic-bootstrap": false, with a cable connected to IPv4 network
"backhaul-dynamic-bootstrap": true, with a cable connected to pure IPv6 network

I had made a fix PR.

[SeppoTakalo]

Thanks for reporting. I also noticed the same.
The used multicast address seems to be Thread specific.

Two solutions exists for this problem:

1. Make up a unique multicast address and join into it. Don't rely on default ones. (Also, make sure that MPL is enabled in 6LP)
2. Use default ones that exists on both Thread and 6LoWPAN-ND.

@kjbracey-arm Which one should we prefer?

[ciarmcom]

ARM Internal Ref: ONME-3204

[kjbracey]

Creating and defining your own group for your own protocol is always preferred to effectively "broadcasting" to all devices. The distinction may not seem relevant when all addresses end up using a MPL multicast flood within a PAN, but if you ever want to start communicating across wider chunks of network PANs it will matter.

No RFC formally defines "ff03::1", so the core Nanomesh stack in base 6LoWPAN config doesn't join that group; the Thread spec does mandate it, so the Thread bootstrap does.

Maybe the core config should be adjusted to always join it - other specs like ZigBee IP and Wi-SUN specify it, and mesh people do tend to assume it works. Previously it did.

It seems that the base 6LoWPAN setup may also not be activating MPL now? That's another change to the previous default for a simple mbed OS app.

Perhaps LoWPANNDInterface should take care of this - default to turning on MPL unless configured otherwise.

[SeppoTakalo]

@mikter @karsev Example of how to join a multicast group in Mbed OS

    my_socket = new UDPSocket(network_if);
    my_socket->setsockopt(SOCKET_IPPROTO_IPV6, SOCKET_IPV6_MULTICAST_HOPS, &multicast_hops, sizeof(multicast_hops));

    ns_ipv6_mreq_t mreq;
    memcpy(mreq.ipv6mr_multiaddr, multi_cast_addr, 16);
    mreq.ipv6mr_interface = 0:

    socket_setsockopt(my_socket, SOCKET_IPPROTO_IPV6, SOCKET_IPV6_JOIN_GROUP, mreq, sizeof mreq);

No who takes this into the backlog? To my understanding, the 6LoWPAN-ND probably does not enable MPL by default, it should be enabled to get same effect when using either Thread/6LoWPAN

[kjbracey]

If looking to choose a group ID, for site-local the form ff15::Xxxx:xxxx would be appropriate - the "1" at the start indicates "made-up", as does bit 31 being set. Have the bottom 31 bits be random.

Here's one I've chosen for you: ff15::810a:64d1. (You could also use the same group ID in any scope, if you want).