OpenThread
[Question] [MLE] Border router initialisation #9727
-
|
Hello This issue is just for questions about MLE. First, the story: We find out that when we create a thread network (1) if just after we commission a Matter (Thread) device, it is always failing on the first mDNS attempt to discover the device. (FindOperational step), then on the second attempt (45s later) it discovers the device in less that 1 seconds. So we decide to investigate to know why the first mDNS discover whas always failing. We identify that the problem appear only if we create a thread network (1) and immediately commission a matter device. (1) We create the network with these commands: If we wait for the "network to be ready" before commissioning the matter device, it seems ok:
And now I have some questions about this experiment. The questions will be based on the MLE logs of otbr-agent mixed with matter-commissioniner logs (but full logs are attached separatly) Questions:
Full logs: |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 1 reply
-
Just configuring a new network does not invalidate the other state that indicates the device was previously in the Leader role. I would suggest using the
Thread 1.3.0 sets
Try using the
Observing the Thread role state is a good indicator if when the device is attached to a Thread network. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks you so much! With a factoryreset we don't have all the steps with 6x Link Request in timeout of 5s (+/-10%) so it reduce drasticly the network creation time.
So now when we create the thread networks, it takes 10.8s to be ready:
|
Beta Was this translation helpful? Give feedback.
-
|
Hello, I have a new question, I'm going to ask here because it is highly related. I try to understand why the thread device is doing the DNS Update (addressQuery + dnsUpdate) only 7seconds after being attached. Do you have any ideas ? Here there is a sequence diagram based on otbr-agent logs:
Attached you will find the full logs of otbr-agent and the sources of this plantuml diagram. appairage_eve.txt Also, on the past we had the logs of the ot-ctl commands in the otbr-agent logs, but now (since long time), we don't have it. Did you know how to display the commands executed by ot-ctl in otbr-agent logs ? Note: The logs that you see like this |
Beta Was this translation helpful? Give feedback.
-
Take a look at #8318, which may help avoid the need to resolve the SRP Server's address.
I believe this is due to #8994 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! With your link I also find related issues/discussions:
The problem explained here: #9416 (comment) is exactly what I see, but I'm not sure if the source of the problem is the same, because in my case I don't have the But it's not clear to me if their logs are "device side" or "otbr-agent side", it's possible that it's "device side". Also it's not clear to me if this PR must be present "device side" or "otbr-agent side": #8318 if it's otbr-agent side, I will try it. |
Beta Was this translation helpful? Give feedback.
-
|
The enhancement in #8318 avoid the need to send an Address Query message in certain situations. In your scenario, the device side is sending the Address Query, so this optimization needs to be on the device side. |
Beta Was this translation helpful? Give feedback.
Just configuring a new network does not invalidate the other state that indicates the device was previously in the Leader role. I would suggest using the
factoryresetCLI command to clear out the other state as well.Thread 1.3.0 sets
MLE_MAX_CRITICAL_TRANSMISSION_COUNTto 6.