net: openthread: Fix the handling of address state changes #77210
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The #76671 fixed the issue where a deprecated address might have been used as a source address, leading to routing issues until the address was completely removed. What was missed in the implementation was the case where the address changes its state back to "preferred" from "deprecated." In such case OpenThread emits
OT_CHANGED_IP6_ADDRESS_REMOVED
andOT_CHANGED_IP6_ADDRESS_ADDED
events, but it does so simultaneously in one callback and without the hard removal that was previously assumed. This commit simply removes the if-statement, allowing the address state to be set at any time, whether during the initial addition of the address or during any update. Btw. I believe the current implementation of synchronization of the addresses coulb be simplified by utilizing a new APIotIp6SetAddressCallback
- i can look at this in the future.Testing was conducted manually by removing/adding the prefix and observing the
net ipv6
shell output.Additionally, during static code analysis, I believe I found an issue with prefix comparison in the
is_mesh_prefix
function. It was assumed that the prefix was the size of a pointer, which in rare situations, where the mesh-local prefix and on-mesh prefix have the same first bytes, may lead to a situation where no communication can occur.