THREAD: Duplicate IPv6 address

[philippeL]

Dear ST Support Team,

I am using STM32WB55 with firmware stm32wb5x_BLE_Thread_dynamic_fw.bin release V1.23 and application based on samples in STM32CubeFW. I flashed two devices and set both devices:

• OT_LinkMode.mRxOnWhenIdle = 1U;
• OT_LinkMode.mDeviceType = 1U;
• OT_LinkMode.mNetworkData = 1U;

and coap capabilities.

I noticed the following behaviour:

Device1:

• EUI-64: 76:1A:D6:A4:98:A7:2C:70
• Preferred IPv6: fdeb:6e2:6135:d326:0:ff:fe00:5c00
• Preferred IPv6: fdeb:6e2:6135:d326:23d4:335f:27aa:3a48
• Preferred IPv6: fe80:0:0:0:741a:d6a4:98a7:2c70
• RLOC16: 0x5c00

Device2:

• EUI-64: 76:1A:D6:A4:98:A7:2C:70
• Preferred IPv6: fdeb:6e2:6135:d326:0:ff:fe00:5402
• Preferred IPv6: fdeb:6e2:6135:d326:23d4:335f:27aa:3a48
• Preferred IPv6: fe80:0:0:0:741a:d6a4:98a7:2c70
• RLOC16: 0x5402

Both devices have the same extAddr and same IPv6! (eui-64 read thanks otLinkGetExtendedAddress(...) ).

If I use otLinkSetExtendedAddress(...) with extAdrr coming from reading at @UID64_BASE (according to user manual Flash 64 section) I've got:

Device1:

• EUI-64: 1B:62:79:02:26:E1:80:00
• Preferred IPv6: fdeb:6e2:6135:d326:0:ff:fe00:a000
• Preferred IPv6: fdeb:6e2:6135:d326:23d4:335f:27aa:3a48
• Preferred IPv6: fe80:0:0:0:1962:7902:26e1:8000
• RLOC16: 0xa000

Device2:

• EUI-64: EB:A9:CC:01:26:E1:80:00
• Preferred IPv6: fdeb:6e2:6135:d326:0:ff:fe00:c002
• Preferred IPv6: fdeb:6e2:6135:d326:23d4:335f:27aa:3a48
• Preferred IPv6: fe80:0:0:0:e9a9:cc01:26e1:8000
• RLOC16: 0xc002

They still have the same IP address: fdeb:6e2:6135:d326:23d4:335f:27aa:3a48!

Any idea where I have to look for to avoid such behaviour? Because right now devices are only able to react on put/post multicast coap messages.

Thanks in advance.

Kind regards.

Philippe.

[STTwo-32]

Hello @philippeL 

Thank you for coming to the ST Community. This behavior is under investigation (under internal ticket number 218031). We will be back to you ASAP.

Best Regards

STTwo-32

[Ouadi · Accepted solution]

Hi @philippeL,

This case has been solved. 

Please find the answer below :

Ipv6 adresses are generated on CPU2  using the RNG Hardware peripheral based on noise source, the generation is done at the initialisation phase of Openthread.

The problem occurs when the application also uses this peripheral. In that case, it must be initialized after OT init, Otherwise, it may cause a misconfiguration of the peripheral on CPU2 side.

MX_RNG_Init() should be placed after APP_THREAD_Init_Dyn_2() to ensure a proper generation of IPV6 adresses. 

Regards,

Ouadi