tree 3c56a20149ebaf451fdb01e55c43ef25b609e3fe
parent cc003b3a42f732ad42bc03297f4b52f2b5a350d6
author Abtin Keshavarzian <abtink@google.com> 1651869390 -0700
committer GitHub <noreply@github.com> 1651869390 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJidYbOCRBK7hj4Ov3rIwAAoTgIAJ39EGPg5QNmLuLGncz1ASbD
 SgIL3diskquyqMBoyMJIXrHOKwenSrHcC00VLzutZ3nyymbLL5lqfVbjaw09eYo0
 k5m11aMPjeWKSqSwyhjzoQxeHnBrs2r1fxkRJD3mAqQUk4hz5m205oJB7MIDOSmw
 BSTzfYioa5LFsCSJmqQOi69J/rH299KIWM3ztT9NlI/iP/M+lLT1htEfLtKSA28P
 FgX3RwbrbVRuU3M+gTf+nEv1Y7lB7n14xRqYBFSr5V+dHcGTT+8FIv+bRgOq8VT6
 f5K3YilQsO+cOgqbBO9D0Gajq9l2p3Jb82zqjsvZ1JbZX+Y1MT1Au5nepr9F+tA=
 =5Iit
 -----END PGP SIGNATURE-----
 

[mle] enhance `ProcessRouteTlv()` to update neighbor pointer (#7667)

This commit updates `MleRouter::ProcessRouteTlv()` to not only read
and process Route TLV from a received MLE message but also to update
the `mNeighbor` pointer (in `RxInfo`) which indicates the neighbor
from which the MLE message was received.

During processing of Route TLV, the entries in the router table may
shuffle. If the `mNeighbor` was pointing to an entry in `RouterTable`
it may be invalid afterwards. The new implementation ensures that
`mNeighbor` is correctly updated to point the same entry.

This change addresses a scenario where in `Mle::HandleAdvertisement()`
a potentially invalid (or set to null) `mNeighbor` may be checked
after Route TLV is processed from `MleRouter::HandleAdvertisement()`
call.