| commit | 9f0df3049356d4d64c154b2a7c0a555fb2629044 | [log] [tgz] |
|---|---|---|
| author | Eduardo Montoya <edmont@users.noreply.github.com> | Tue Jul 07 20:40:26 2020 +0200 |
| committer | GitHub <noreply@github.com> | Tue Jul 07 11:40:26 2020 -0700 |
| tree | d353f6b3b91d28286b41de5c6330deaae575448c | |
| parent | d3a429b1eaa7269f55de2127116cb68a6661b086 [diff] |
[meshcop] JR: don't wait for previous rsp to send a new JOIN_ENT.ntf (#5199) The existing Joiner Entrust process is as follows: - The Joiner sends JOIN_FIN.req and receives JOIN_FIN.rsp from the Joiner Router. - The Joiner sets up a 4000 ms timer to receive the JOIN_ENT.ntf. - The Joiner Router generates the JOIN_ENT.ntf and enqueues it, setting up a 50 ms timer to send it. - When the Joiner Router timer triggers it sends the heading message from the queue ONLY if the previous transaction already completed. This is done like this because whenever a new JOIN_ENT.ntf is sent the KEK in the KeyManager is changed, and it's required to keep it in order to decrypt the CoAP ACK. This approach presents a couple of issues: - It blocks the message queue up to the maximum CoAP transaction time, which can be much longer than the Joiner 4 seconds timeout. - Even worse, if the CoAP ACK never arrives, no more messages would be released from the queue, even future enqueued ones. This commit removes this queue blocking, assuming the risk of an enqueued JOIN_ENT.ntf being sent before the previous ACK has arrived. In that case there are two options: - The previous JOIN_ENT.ntf was not delivered and the previous Joiner would need to start over the whole Commissioning process again. - The previous JOIN_ENT.ntf was delivered but the ACK was not received. This has impact only in the Joiner Router logs. But even for the first case the chances are very low (a JOIN_ENT.ntf enqueued to be triggered just a few milliseconds after the first one) and situation is much better than the previously existing one.
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.