Trying to get the realm local address, and verifying the multicast functionality of OTBR

[ZhouJooJoo]

hi there,

I am currently trying to use the samples of "ncs/nrf/samples/openthread/coap_server" and "coap_client". I have flashed them onto two nrf52840dk_nrf52840 development boards. I have called the API to attempt to obtain the realm local multicast address and tried to use OTBR running on a Raspberry Pi to send multicast packets to the realm local multicast address. My ultimate goal is to verify whether messages sent to the realm local address in the Thread network will be resent twice due to the MPL mechanism. At the moment, I have the following questions:

1. When I obtain the realm local multicast address, does it mean that devices in the Thread network composed of coap_server and coap_client have all subscribed to this realm local address? If I send multicast packet information to this address, can they receive it? if they still not subscribe the address, what should i do to let them subscribe it?

2. How can I verify the information sent to the multicast address? The methods I am currently considering are using a dongle to capture packets in the air(sniffer) for verification or printing the received multicast information in the RTT viewer window. However, I lack experience in this and would like to know if there are similar samples that I can refer to.

3. i tried to use the RTT viewer to print the realm local address i got, but the realm local address stays the same for ALL THE TIME, every time they got the same result.
   the realm local address will be : 33ff:4000:d9fd:08a6:197b:899a:0000:0100, but as far as i know, the realm local addrees depneds on the mesh local prefix,Could it be that every time I start two development boards, their mesh local prefixes are the same?Maybe there are some deviations in my understanding. I hope you can correct me. Thank you very much.
   i would be appreciate if anyone could answer the questions, many thanks!

best regards,

Zhou

[jwhui]

1. When I obtain the realm local multicast address, does it mean that devices in the Thread network composed of coap_server and coap_client have all subscribed to this realm local address? If I send multicast packet information to this address, can they receive it? if they still not subscribe the address, what should i do to let them subscribe it?

All devices will automatically subscribe to the realm-local All Thread Nodes address.
Routers will automatically subscribe to the realm-local All Thread Routers address.
All devices must explicitly subscribe to any other realm-local multicast address.

2. How can I verify the information sent to the multicast address? The methods I am currently considering are using a dongle to capture packets in the air(sniffer) for verification or printing the received multicast information in the RTT viewer window. However, I lack experience in this and would like to know if there are similar samples that I can refer to.

Packet sniffer would provide visibility into packets transmitted and the IPv6 destination address contained within.

Logs would provide visibility into packets received.

3. i tried to use the RTT viewer to print the realm local address i got, but the realm local address stays the same for ALL THE TIME, every time they got the same result.
   the realm local address will be : 33ff:4000:d9fd:08a6:197b:899a:0000:0100, but as far as i know, the realm local addrees depneds on the mesh local prefix,Could it be that every time I start two development boards, their mesh local prefixes are the same?Maybe there are some deviations in my understanding. I hope you can correct me. Thank you very much.

Yes, realm-local multicast address is derived from mesh-local prefix.

[ZhouJooJoo]

thanks for the advice! I verified that the python script can do this work, and know i would like to use another way which is more convinient and light to send the message--"using the ot command."

'1234' is the port number, and i use the wireshark to capture the data, it seems the meessages were sent, however, there are continuous udp messages, which are one byte larger than the normal packet, when i look into the data, it contains one more data, the hoop limit, do you know why is that? or should i use any other OT command to send messages?

Many thanks!!

[jwhui]

Thread forwards IPv6 multicast messages by having the routers transmit them as broadcast messages multiple times. The multicast message should include an IPv6 Hop-by-Hop Option, which allows Thread devices to filter out duplicate receptions.

[ZhouJooJoo]

thanks for your reply. just to clarify that, among the results of packet capture from wireshark above, there are two messages with a blue background, which are exactly what I expected, because the address I sent is the realm local address, and under the action of the MPL mechanism, the information was forwarded twice. But I don’t know why the red packet capture information appears. Based on your suggestions, I modified the sending command as follows, and additionally specified the hop limit. However, there are still red packet capture messages. However, this red packet capture information did not appear when I used a python script to send multicast information. I hope you can provide more ideas, thank you.
the revised command i am using to send the packets is listed below:
sudo ot-ctl udp send ff33:0040:fdd9:a608:7b19:9a89:0000:0001 1234 hello hlim=50 time=9ms

[jwhui]

Can you share the pcap file?

[ZhouJooJoo]

sure, here is the packet that i tried to capture, and the phenomenon happens at line 1286-1290, 2758-2766
Uploading nordic TBR.zip…