test_srp_auto_host_address.py 5 failing /100 runs about openthread HOT 9 CLOSED

The proposed approach in #9800 (comment) sounds good to me!

from openthread.

Thinking more on this here is my proposal.

• We remove the change from [#6532] and make sure mesh-local addresses are again marked as preferred within OT core.
• We provide mechanism for the platform code to easily distinguish mesh-local addresses.
• We update the platform code which mirrors/updates the Thread addresses on host network interface to add mesh-local addresses as non-preferred.
  • This platform behavior can be configurable which can provide a solution for #8443.

Setting mesh-local address within OT as deprecated/non-preferred for the host does not align with intended use of mesh-local address within Thread mesh and we see that it does impact the source selection logic.

There are two ways for platform to get the addresses:

• Iterate through the list of otNetifAddress.
  • The otNetifAddress struct already provides mMeshLocal to indicate that address is mesh-local
• Register a callback using otIp6SetAddressCallback() and getting otIp6AddressInfo
  • We can add a mMeshLocal field in otIp6AddressInfo as well to make it easier for platform.

Thoughst? @jwhui @librasungirl @bukepo

from openthread.

A quick local validation with a build w/o #9634 1000/1000 PASS
@abtink seems related to this PR #9634

from openthread.

Manually added address is always preferred, and has global scope by default; MeshLocal address is of RealmLocal scope and init as non-preferred by default.
When SelectSource, in the for() loop, if Manually added address is after MeshLocal address in the interface's unicast address array, the Manually added address will win as it's preferred.

Here with #9801 which init MeshLocal address as preferred, this test can pass 1000/1000 runs。

Any more context to mark mesh local as non preferred？thoughts on the quick fix #9801? @abtink

from openthread.

Thanks @librasungirl for debugging this. 👍.

I had noticed the frequent test failures and AssertError(kRefresh) state recently and was planning to investigate when I had some time. I suspected a timing issue where we might be checking for registration too early. Glad you found the root cause! 😃

On #9801 and marking mesh local as preferred, it makes sense to me, but I wonder why was it not set as such before?

• If I am not mistaken, this has been always the case in OT stack? Was it an omission or may be intentional?
• I wonder if marking mesh-local as preferred may cause issues on platform side where Thread interface addresses are mirrored on wpan interface (having mesh-local addresses be marked as preferred?)
• I feel safer not change it without knowing more about the reasons behind this?

Related to PR #9634:

• It is a correct/important fix for a bug in SelectSource().
• But I think the unfortunate side-effect of this bug was that it masked this situation making the srp_auto_address test work reliably.

Some ideas:

• We can update the test itself. It is adding a new address without adding a prefix for it in netdata? So I think the address is practically not usable/reachable? We can add a (non-SLAAC on-mesh) prefix for it in the test case?
• We can add a new rule to SelectSource() to always pick mesh-local source if dest is also mesh-local?
  • We already have a similar rule which picks RLOC when dest is RLOC.
  • This seems reasonable to me and may be a good enhancement to add anyways. Thoughts?

from openthread.

I did a bit of checking through the code/commit history. The mesh-local addresses were originally marked as preferred but this was changed in this PR (from ~May 2021)

• #6532

This commit marks anycast addresses and mesh-local addresses as IPv6 non-preferred addresses.

The background is host IPv6 stack(such as lwIP, Linux kernel and so on) cannot tell these addresses to OMR addresses from the scope id. By marking these addresses non-preferred, the host IPv6 stack will not select these addresses as the source address of application layer traffic unless explicitly assigned.

from openthread.

A related issue:

• #8443

from openthread.

Submitted

• #9815

from openthread.

We can close this as #9815 is merged.

from openthread.