Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

RE: Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

Edvin — Wed, 16 Sep 2020 08:09:26 GMT

Hello,

I received a reply today:

In case you have full control of the Thread network, you can pre-commission the devices with specific Mesh Local Prefix by using the function:

otThreadSetMeshLocalPrefix() (https://github.com/openthread/openthread/blob/master/include/openthread/thread.h#L457 )

This API has to be called before the interface and Thread is brought up.

On Border Router, if you want to change the default Mesh Local Prefix in the /etc/border_router.conf file, please execute "wpanctl leave & sudo reboot", or else the NCP will use the Operational Dataset stored in the flash.

Please remember that in a regular network, the Mesh Local Prefix might be randomly chosen, and all devices receive the Operational Dataset (which includes the Mesh Local Prefix) during the Commissioning process. We don't have built in support for automatic change of the GatewayUDP6Broadcast value in the paho_mqttsn_gateway.conf gile. What you can do is to implement a small script wich will react on changes of MeshLocalPrefiz from wpantund/wpanctl and adjust the value of the GatewatUDP6Broadcast field and restart the Paho MWTT-SN gateway.

Another alternative could be to subscribe to some random multicast address on all MQTT-SN client devices, including SEDs (e.g. FF03::cafe) using the "otIp6SubscribteMulticastAddress" API (https://github.com/openthread/openthread/blob/master/include/openthread/ip6.h#L307 ) and then use this address in the GatewayUDP6Broadcast field. This way, you won't be dependent on the MeshLocalPrefix, but at the same time you will create a proprietary solution.

BR,

Edvin

RE: Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

Edvin — Fri, 07 Aug 2020 14:33:28 GMT

I don't see why that would be necessary, and why not just reading it out would be just as good, but I can check with our Thread team.

I'll let you know when I hear from them.

Best regards,

Edvin

RE: Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

MarcoLG — Thu, 06 Aug 2020 12:35:36 GMT

I don't want to fetch the IPv6:MeshLocalPrefix, i want to set it to a predetermined value, so that i can hardcode it into the paho_mqttsn_gateway.conf file under the GatewayUDP6Broadcast option.

RE: Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

Edvin — Thu, 06 Aug 2020 10:35:20 GMT

So I assume that your border router is using a dongle or a DK to communicate with the mesh network, right? You want to be able to fetch this IPv6:MeshLocalPrefix from your border router without using the wpanctl status command from your command line, but using a CLI command, is that correct?

If so, did you try to use the "dataset" command after forming the network?

Please see the guide on how to form the network:
https://infocenter.nordicsemi.com/topic/sdk_tz_v3.2.0/thread_ot_commissioning_configuring.html?cp=7_7_1_2_7_5_0_0_2#thread_ot_commissioning_configuring_on-mesh_cli_forming

Let me know if this is not what you are looking for.

Best regards,

Edvin

RE: Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

MarcoLG — Wed, 05 Aug 2020 13:02:18 GMT

Hello,

no it is basically the opposite.

The border router (which includes the mqttsn gateway) is alway on and forms the thread network when it boots up. It is the only router node in the network.

The other devices sleep most of the day (they are not connected and in low power mode) and periodically wake up. When they wake up, they try to connect to the network, then try to discover the mqttsn gateway, connect to it and finally publish some content. Then, they return to sleep.

What i'm observing is that when a device wakeup, it connects to the thread network as child (as expected), then it broadcasts a mqttsn gateway search packet to the multicast address ff03::1. The problem, now, is that when the gateway responds to this message, it should broadcast the response to the realm-local unicast prefix-based multicast address in order for the message to be forwarder to the child node during the next poll (the child, as i said, is configured with THREAD_RADIO_MODE_RX_OFF_WHEN_IDLE so it will not receive messages sent to ff03::1). The unicast prefix-based address, on the other hand, depends on the thread mesh local prefix, which i have been unable to set. When the router forms the network, it sets a mesh local prefix that appears randomly generated. As a consequence, I don't know how to set the GatewayUDP6Broadcast option in the border router mqttsn gateway config file.

Just to be as clear as possible, i'm referring to the "IPv6:MeshLocalPrefix" => "fdc0:de1a:b5c0::/64" that appears when i write "sudo wpanctl status" after forming the thread network. See the below command output:

pi@raspberrypi:~ $ sudo wpanctl status
wpan0 => [
"NCP:State" => "associated"
"Daemon:Enabled" => true
"NCP:Version" => "OPENTHREAD/20191113-00534-gc6a258e3; NRF52840; Apr 5 2020 21:51:18"
"Daemon:Version" => "0.08.00d (; Apr 21 2020 19:11:43)"
"Config:NCP:DriverName" => "spinel"
"NCP:HardwareAddress" => [F4CE366E33AE613F]
"NCP:Channel" => 11
"Network:NodeType" => "leader"
"Network:Name" => "MSquare-Test"
"Network:XPANID" => 0xC0DE1AB5C0DE1AB5
"Network:PANID" => 0xABCD
"IPv6:LinkLocalAddress" => "fe80::1cb9:e183:e22c:3816"
"IPv6:MeshLocalAddress" => "fdc0:de1a:b5c0:0:efd2:518b:d2c8:c4c3"
"IPv6:MeshLocalPrefix" => "fdc0:de1a:b5c0::/64"
"com.nestlabs.internal:Network:AllowingJoin" => false
]

RE: Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

Edvin — Wed, 05 Aug 2020 12:13:05 GMT

[quote user=""]I configured my end devices as sleepy end devices (setting radio_mode = THREAD_RADIO_MODE_RX_OFF_WHEN_IDLE in thread_configuration_t structure),[/quote]

Does this mean that the nodes have a parent node that is always awake, or do you disconnect from the network, and reconnect once of twice per day?

RE: Nordic (OpenThread) Thread Border Router - Mesh Local Prefix

Edvin — Wed, 05 Aug 2020 12:12:01 GMT

Hello,

So the devices are not connected to the network most of the time, but from time to time you want to send messages from the border router to the nodes (when they wake up?). Is that correct?

I don't know if it is possible to predict the addresses, since this is decided when the network is formed, I guess. How about storing the assigned addresses when the nodes connect to the network? Did you try something like this?

What is your plan for the messages that you try to send out to all nodes when nodes are not connected to the network? Is the plan to store them until they wake up, or to send to the devices that are awake at this point in time?

To be honest, I don't know the answer to your questions by heart, but perhaps if I understand the use case scenario, I can check with our Thread team.

Best regards,

Edvin