| commit | 2129daaf21902b93829d929103ce15b8e8ec14dc | [log] [tgz] |
|---|---|---|
| author | Simon Lin <simonlin@google.com> | Mon Dec 27 15:15:02 2021 +0800 |
| committer | GitHub <noreply@github.com> | Sun Dec 26 23:15:02 2021 -0800 |
| tree | d7c87708154cb48fd048852e3d93db11eded5228 | |
| parent | d47dea0b6f294b1a5ee22e5cbf34f7a1573b9603 [diff] |
[border-routing] fix stale prefixes checking timer (#7241)
Current implementation will reschedule the Stale Timer when discovered
on-link or OMR prefixes or RA messages are updated, but it has a few
issues:
1. It's counting the maximum stale time of all on-link prefixes so
that we will schedule Router Solicitation when all on-link
prefixes become stale. But it failed to filter out OMR prefixes in
the `mDiscoveredPrefixes` list. This results in incorrect stale
time calculation.
2. A deprecated on-link-prefix is not removed from
`mDiscoveredPrefixes` directly but the preferred lifetime is set
to zero. We are not filtering out deprecated on-link prefixes when
calculating stale time and this results in zero stale timer delay
if there are no non-deprecated on-link prefixes.
This commit fixes those issues by having a dedicated
`ResetDiscoveredPrefixStaleTimer` to reschedule the stale timer with
following rules whenever discovered prefixes or learnt RA messages are
updated:
1. If BR learns RA header from Host daemons, it should send RS when
the RA header is stale.
2. If BR discovered any on-link prefix, it should send RS when all
on-link prefixes are stale.
3. If BR discovered any OMR prefix, it should send RS when the first
OMR prefix is stale.
`ResetDiscoveredPrefixStaleTimer` is supposed to correctly calculate
stale timer timeout whenever it's called.
OpenThread released by Google is...
...an open-source implementation of the Thread networking protocol. Google Nest has released OpenThread to make the technology used in Nest products more broadly available to developers to accelerate the development of products for the connected home.
...OS and platform agnostic, with a narrow platform abstraction layer and a small memory footprint, making it highly portable. It supports both system-on-chip (SoC) and network co-processor (NCP) designs.
...a Thread Certified Component, implementing all features defined in the Thread 1.1.1 specification, including all Thread networking layers (IPv6, 6LoWPAN, IEEE 802.15.4 with MAC security, Mesh Link Establishment, Mesh Routing) and device roles, as well as Border Router support.
More information about Thread can be found at threadgroup.org. Thread is a registered trademark of the Thread Group, Inc.
All end-user documentation and guides are located at openthread.io. If you're looking to do things like...
...then openthread.io is the place for you.
Note: For users in China, end-user documentation is available at openthread.google.cn.
If you're interested in contributing to OpenThread, read on.
We would love for you to contribute to OpenThread and help make it even better than it is today! See our Contributing Guidelines for more information.
Contributors are required to abide by our Code of Conduct and Coding Conventions and Style Guide.
OpenThread follows the Semantic Versioning guidelines for release cycle transparency and to maintain backwards compatibility. OpenThread's versioning is independent of the Thread protocol specification version but will clearly indicate which version of the specification it currently supports.
OpenThread is released under the BSD 3-Clause license. See the LICENSE file for more information.
Please only use the OpenThread name and marks when accurately referencing this software distribution. Do not use the marks in a way that suggests you are endorsed by or otherwise affiliated with Nest, Google, or The Thread Group.
There are numerous avenues for OpenThread support:
openthread tagThe openthread-users Google Group is the recommended place for users to discuss OpenThread and interact directly with the OpenThread team.