OTBR cannot switch to Leader

[aaa147147]

Describe the bug A clear and concise description of what the bug is.
OTBR cannot switch to Leader -> Error 27: NotCapable
To Reproduce Information to reproduce the behavior, including:

1. Git commit id: ->Commit 147de7e
2. IEEE 802.15.4 hardware platform -> RCP: RTL8771HTV SOC: Amlogic S905X5M
3. Build steps -> Attachment<options.cmake.txt>
4. Network topology -> I don't know how to describe it, can you give me more specific tips

Expected behavior A clear and concise description of what you expected to happen.
OTBR switches to Leader normally

Console/log output If applicable, add console/log output to help explain your problem.
We conducted a power on/off test, and the log showed that during the 88th power on/off test, the status could not be switched to Leader
The 89th test log we have attached can be switched to Leader normally

Additional context Add any other context about the problem here.
Attachment<88.log> -> Error
Attachment<89.log> -> OK

[aaa147147]

88.log
89.log
options.cmake.txt

[aaa147147]

Displayed in<995. log>, unable to switch to leader, and meshdiag topology children ip6 addrs returned timeout

995.log

[jwhui]

The state leader command calls Mle::BecomeLeader(). The NotCapable error is returned in the following cases:

openthread/src/core/thread/mle_router.cpp

Line 281 in 7b72e97

VerifyOrExit(IsRouterEligible(), error = kErrorNotCapable);

openthread/src/core/thread/mle_router.cpp

Line 285 in 7b72e97

VerifyOrExit(mLeaderWeight > mLeaderData.GetWeighting(), error = kErrorNotCapable);

I suspect the error is due to the second case, which indicates that the device is already attached.

[aaa147147]

@jwhui Thanks for your reply
Our current approach is to first change the leaderweight to 255, then state leader for switch the role to leader

So, what checks do we need to do before switching roles to leaders to ensure that we can switch roles to leaders

[jwhui]

It would be good to check whether the device is already attached and, if attached, check the leader weight of the partition it is currently attached to.

[aaa147147]

@jwhui Okay, in the next test, before modifying the leader weight, we will use the leaderweight state commands to check the current state

[aaa147147]

@jwhui In fact, obtaining the connection status and leader weight value is only for our next step of problem localization.

For example, when the state is child and the leader weight is 64, we cannot switch to leader, but first switch to router and then switch to leader

Is there some similar requirements?

[jwhui]

I don't think so. See the BecomeLeader() implementation the checks that are in place:

openthread/src/core/thread/mle_router.cpp

Line 267 in 7b72e97

Error MleRouter::BecomeLeader(bool aCheckWeight)