From f976db5c4cbca9da1ea8632261ab25616a0652e8 Mon Sep 17 00:00:00 2001 From: Rongli Sun Date: Thu, 9 Jan 2020 00:39:10 +0800 Subject: [PATCH] [mle] link sync enhancement (#4427) There is chance for below scenario: 1) Device newly becomes router and sends multicast Link Request (challenge1), 2) Device receives MLE advertisement from one neighbor, and sends unicast Link Request (challenge2), 3) The neighbor ignores the unicast link Request in 2) and sends out Link Accept and Request message as response for 1) 4) Device would drop the Link Accept adn Request message in 3) as it compares the Response TLV value with challenge2, which in fact matches challenge1. The link between Device and the neighbor could not be established until Device receives next MLE advertisement from the neighbor. This commit suppresses unicast Link Request in 2) if there is multicast Link Request ongoing. Thus the three-handshakes link sync could go well. --- src/core/thread/mle_router.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/core/thread/mle_router.cpp b/src/core/thread/mle_router.cpp index a1619a9f2..40c6c95a0 100644 --- a/src/core/thread/mle_router.cpp +++ b/src/core/thread/mle_router.cpp @@ -1397,8 +1397,8 @@ otError MleRouter::HandleAdvertisement(const Message & aMessage, router = mRouterTable.GetRouter(routerId); VerifyOrExit(router != NULL); - // Send link request if no link to router - if (!router->IsStateValid() && !router->IsStateLinkRequest() && + // Send unicast link request if no link to router and no unicast/multicast link request in progress + if (!router->IsStateValid() && !router->IsStateLinkRequest() && (mChallengeTimeout == 0) && (linkMargin >= OPENTHREAD_CONFIG_MLE_LINK_REQUEST_MARGIN_MIN)) { router->SetExtAddress(macAddr);