openthread: EFR32 Joining failure

The joining process between two EFR32 wireless dev kits fails.

Load one dev kit with ot-cli-mtd (joiner/child) and one with ot-cli-ftd (leader/commissioner).

On the leader/commissioner

ifconfig up
thread start
commissioner start
commissioner joiner add * AAAABBBB

On the joiner/child

ifconfig up
joiner start AAAABBBB

CLI output on leader/commissioner

> Commissioner: Joiner start af5570f5a1810b7a
Commissioner: Joiner connect 3e15636229b773af
=========[[THCI] direction=recv | type=JOIN_FIN.req | len=051]==========
| 10 01 01 21 0D 53 4C 2D | 4F 50 45 4E 54 48 52 45 | ...!.SL-OPENTHRE
| 41 44 22 05 45 46 52 33 | 32 23 10 31 2E 30 2E 30 | AD".EFR32#.1.0.0
| 2E 32 20 47 69 74 48 75 | 62 2D 66 25 06 18 B4 30 | .2 GitHub-f%..40
| 00 00 10 .. .. .. .. .. | .. .. .. .. .. .. .. .. | ................
------------------------------------------------------------------------
=========[[THCI] direction=send | type=JOIN_FIN.rsp | len=003]==========
| 10 01 01 .. .. .. .. .. | .. .. .. .. .. .. .. .. | ................
------------------------------------------------------------------------
Commissioner: Joiner finalize 3e15636229b773af
[THCI] direction=send | type=JOIN_ENT.ntf
Commissioner: Joiner end 3e15636229b773af
Commissioner: Joiner start af5570f5a1810b7a
Commissioner: Joiner connect 3e15636229b773af
=========[[THCI] direction=recv | type=JOIN_FIN.req | len=051]==========
| 10 01 01 21 0D 53 4C 2D | 4F 50 45 4E 54 48 52 45 | ...!.SL-OPENTHRE
| 41 44 22 05 45 46 52 33 | 32 23 10 31 2E 30 2E 30 | AD".EFR32#.1.0.0
| 2E 32 20 47 69 74 48 75 | 62 2D 66 25 06 18 B4 30 | .2 GitHub-f%..40
| 00 00 10 .. .. .. .. .. | .. .. .. .. .. .. .. .. | ................
------------------------------------------------------------------------
=========[[THCI] direction=send | type=JOIN_FIN.rsp | len=003]==========
| 10 01 01 .. .. .. .. .. | .. .. .. .. .. .. .. .. | ................
------------------------------------------------------------------------
Commissioner: Joiner finalize 3e15636229b773af
[THCI] direction=send | type=JOIN_ENT.ntf
Commissioner: Joiner end 3e15636229b773af

CLI output on joiner/child

> =========[[THCI] direction=send | type=JOIN_FIN.req | len=051]==========
| 10 01 01 21 0D 53 4C 2D | 4F 50 45 4E 54 48 52 45 | ...!.SL-OPENTHRE
| 41 44 22 05 45 46 52 33 | 32 23 10 31 2E 30 2E 30 | AD".EFR32#.1.0.0
| 2E 32 20 47 69 74 48 75 | 62 2D 66 25 06 18 B4 30 | .2 GitHub-f%..40
| 00 00 10 .. .. .. .. .. | .. .. .. .. .. .. .. .. | ................
------------------------------------------------------------------------
=========[[THCI] direction=recv | type=JOIN_FIN.rsp | len=003]==========
| 10 01 01 .. .. .. .. .. | .. .. .. .. .. .. .. .. | ................
------------------------------------------------------------------------
Join failed [ResponseTimeout]

It seems the commissioner thinks the join process worked but the child/joiner has a timeout issue. What’s going on here?

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 29 (16 by maintainers)

Most upvoted comments

An Operational Dataset is the object that encapsulates a Thread network configuration.
An Active Operational Dataset is the Operational Dataset that is currently in use by the Thread device.
A Pending Operational Dataset is an Operational Dataset that is scheduled to be used some time in the near future. Pending operational Datasets are useful when changing Thread network parameters that may affect connectivity (e.g. channel, master key, etc.).
Often times, we say Active Dataset or Pending Dataset as short forms of Active Operational Dataset and Pending Operational Dataset, respectively.
The dataset command manipulates Operational Datasets.
The channel command manipulates the MAC channel directly (completely bypassing Operational Dataset). The channel command is useful for RCP, where the SoC only implements MAC/PHY.
As for parameter value validation, for completeness, we’d need to validate the Operational Dataset to ensure it is consistent. For example, the Channel must be a valid within the provided Channel Mask. That would imply updating the commands to require specifying multiple parameters at a time.
Full details regarding Operational Datasets are available in the Thread 1.1 Specification.

Hope that helps.

jwhui on Sep 15, 2020

Hey Sagar,

I was able to get the Thread network formation figured out. It was that I had the active timestamp set to 0.

Joining was consistent after I figured out that the Active Dataset must be completely clear. A factoryreset is one way to do this.

Thanks, Jake

theHurc on Sep 16, 2020

@JaneFromSilabs , yes, dataset clear will work if you specify every value individually. The risk is that the Operational Dataset may not have some values specified.

dataset init new will ensure that every parameter has some value by initializing each parameter to some value.

jwhui on Sep 15, 2020