Thread commissioning issue

[Yasmine Safi]

Dear OpenThread Team,

I am having trouble with the device joining into Thread network, which was created by OTBR via Thread Commissioning process (https://openthread.io/guides/build/commissioning). Here is the setup I am using:

1. The node that I am trying to commission into network is MGM210P (based on Silicon Labs EFR32MG21) module, which is running OT CLI FTD firmware with following buld configurations (JOINER=1 COMMISSIONER=1 OT_THREAD_VERSION=1.2)
2. As for OT Border Router I am again using MGM210P which runs RCP firmware with following build configurations (COMMISSIONER=1 OT_THREAD_VERSION=1.2). For this test RCP is connected to the host machine (laptop running Ubuntu). I followed the steps described in this page (https://openthread.io/guides/border-router/build) to build the latest version of OTBR application.

After successful build of OTBR I used following commands via ot-ctl tool to form the network and start the commissioning process:

dataset init new
Done
dataset commit active
Done
ifconfig up
Done
thread start
Done
state
leader
Done
commissioner start
Commissioner: petitioning
Done
Commissioner: active

commissioner joiner add * J01NME

After that I sent the following commands to th CLIe FTD node:

factoryreset
ifconfig up
Done
joiner start J01NME
Done

[NONE]=[[THCI] direction=send | type=JOIN_FIN.req | len=051]==
[NONE]| 10 01 01 21 0D 53 4C 2D | 4F 50 45 4E 54 48 52 45 | …!.SL-OPENTHRE
[NONE]| 41 44 22 05 45 46 52 33 | 32 23 10 31 2E 31 2E 32 | AD".EFR32#.1.1.2
[NONE]| 2E 30 5F 47 69 74 48 75 | 62 2D 35 25 06 18 B4 30 | .0_GitHub-5%…40
[NONE]| 00 00 10 … … … … … | … … … … … … … … | …
[NONE]------------------------------------------------------------------------
[NONE]=[[THCI] direction=recv | type=JOIN_FIN.rsp | len=003]==
[NONE]| 10 01 01 … … … … … | … … … … … … … … | …
[NONE]------------------------------------------------------------------------
[NONE]-MESH-CP-: [THCI] direction=recv | type=JOIN_ENT.ntf␍␊
[NONE]-MESH-CP-: [THCI] direction=send | type=JOIN_ENT.rsp␍␊
Join success

thread start
Done
state
detached

As you can see from the above logs, commissioning process went fine and device joined the network, but the state remains detached forever ( in OTBR logs you can see [Child +, Child-] ).

The only way I was able to include the node into the network was by copying full operational dataset from OTBR (dataset active -x) and setting it in the node. After that I could see that it has become a child. Although, even with this solution, I was not able to achieve a simple ping from OTBR to the node, as it was giving 100% packet loss.

P.S. The same process works perfectly when I use two OT CLI FTD modules, instead of OTBR<->RCP combination

Attached you can find part of the logs from otbr-agent after commissioning process. Any help would be appreciated, thanks in advance!

[Kangping Dong]

P.S. The same process works perfectly when I use two OT CLI FTD modules, instead of OTBR<->RCP combination

Is the same openthread commit used for both the OT CLI FTD device and OTBR device?

BRs,

Kangping

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/52be9112-13eb-4b62-92af-338f0fad3514n%40googlegroups.com.

[Yasmine Safi]

we tried this commit 5c2ad91cf  on both RCP and FTD, and we had 2 case: 

1- Problem persists when we set the version to Thread 1.2 ( OPENTHREAD_CONFIG_THREAD_VERSION =3 ) but all Thread 1.2 features are disabled. 

2- Problem solved if we move back to Thread 1.1

[Kangping Dong]

1- Problem persists when we set the version to Thread 1.2 ( OPENTHREAD_CONFIG_THREAD_VERSION =3 ) but all Thread 1.2 features are disabled. 

2- Problem solved if we move back to Thread 1.1

There are 1.2 features that are enabled when OT_THREAD_VERSION is set to 1.2 even when those features are not explicitly specified. @Simon Lin any ideas on the 1.2

compatibility issue?

BRs,

Kangping

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/edcc7e37-0da0-4f9b-88d9-e0be40eeb003n%40googlegroups.com.

[Yasmine Safi]

after debugging I found which define is causing the issue exactly in RCP:
OPENTHREAD_CONFIG_MAC_SOFTWARE_TX_SECURITY_ENABLE
more specifically in mac_frame.cpp inside the function  TxFrame::ProcessTransmitAesCcm(const ExtAddress &aExtAddress) 

if I disable the line SuccessOrExit(GetFrameCounter(frameCounter));  everything works, and I am able to do the commissioning process

are we missing something here ?

[Kangping Dong]

I am not very clear of the root cause, would you try the latest openthread and OTBR master commit to see if the issue persists?

BRs,

Kangping

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/5dc69a5d-a5e4-48ff-8e1d-efce09a2382bn%40googlegroups.com.

[Sébastien Parent-Charette]

Hello Yasmine, everyone else,

Since you mentioned commit 5c2ad91cf, I assume you are using the latest release of Silabs GSDK / OT SDK 1.1.x? If so, thank you for the information above about this issue (and potential workaround/breadcrumbs to the root cause). I'll pass this along right away to our team to ensure we are aware of this and I'll try and reproduce the problem you describe internally to get more info for them.

As a side note, if you are using Silabs' OT SDK please note that OT specs 1.2 support is in alpha in that release. You can read more about it here.

Sincerely,

[Yasmine Safi]

Hello Sebastien,

Thank you for your answer.

Yes, we're using last SDK release

[Sébastien Parent-Charette]

Hi Yasmine,

Thanks for confirming.

I have the following update for you:

1) The devs on our side were already aware of this issue. The proper fix is in our platform abstraction layer and was related to the handling of the TX_SECURITY flag from the RCP. From what I understand, they have a working fix.

2) You can get the fix in this PR.

I hope this helps and please do let me know if you have other issues of this type with this update! We'll do our best to address it ASAP.

Sincerely,

[Sébastien Parent-Charette]

P.-S.: I forgot to mention this fix will be available in the official Silabs GSDK in an upcoming patch.

[Sébastien Parent-Charette]

Ah, one more detail I should've mentioned. The PR above (and its relevant update/fix to the GitHub PAL) will only be used if you build the project using the GitHub tools. If you are using Simplicity Studio to build your project (and thus the GSDK latest release), it will not use that patch and therefore you will still have the issue.

Let me know if you are using SSv5 to build your projects and I'll investigate if we can force the use of the GitHub PAL instead (who doesn't fixes, right? :D ) so you don't have to wait for the official update.

Le mardi 27 avril 2021 à 11 h 18 min 24 s UTC-4, Sébastien Parent-Charette a écrit :

[Yasmine Safi]

We are currently using SSv5 to build projects, it would be really helpful if we don't have to wait for the official release 

Thanks alot for your help!

[Sébastien Parent-Charette]

Hi Yasmine,

I'll see if this can be done easily though I'm starting to think it might not be as trivial as I first thought (my bad!). I'll get back to you here as soon as I have more info on this.

In the meantime, feel free to try the GitHub Tools if you can/are interested in trying it out. This is certainly a way to sometimes get access to fixes/new features before they are official in the future. That being said I really do like using SSv5 too to configure and build my projects so I understand if you prefer sticking to that.

Sincerely,

[Yasmine Safi]

Hi Sebastien, 

Thank you for clarifying the issue we're having and providing alternatives :)