Skip to content

Conversation

@zephyrbot
Copy link

@zephyrbot zephyrbot commented Feb 14, 2025

Backport 02c153c~3..02c153c from #85673.

Fixes #85674

When Router Advertisement with Source Link-Layer Address option is
received, host should register a new neighbor marked as STALE
(RFC 4861, ch. 6.3.4). This behavior was broken however, because
we always added a new neighbor in INCOMPLETE state before processing
SLLA option. In result, the entry was not updated to the STALE state,
and a redundant Neighbor Solicitation was sent.

Fix this by moving the code responsible for adding neighbor in
INCOMPLETE state after options processing, and only as a fallback
behavior if the SLLA option was not present.

Signed-off-by: Robert Lubos <[email protected]>
(cherry picked from commit fce5392)
According to RFC 4861, ch. 7.3.3:

 "Upon entering the PROBE state, a node sends a unicast Neighbor
  Solicitation message to the neighbor using the cached link-layer
  address."

Zephyr's implementation was not compliant with behavior, as instead of
sending a unicast probe for reachability confirmation, it was sending a
multicast packet instead. This commit fixes it.

Signed-off-by: Robert Lubos <[email protected]>
(cherry picked from commit 8cd213e)
According to RFC 4861, ch. 7.2.5:

 "If the Override flag is set, or the supplied link-layer address
  is the same as that in the cache, or no Target Link-Layer Address
  option was supplied, the received advertisement MUST update the
  Neighbor Cache entry as follows

  ...

  If the Solicited flag is set, the state of the entry MUST be
  set to REACHABLE"

This indicates that Target Link-Layer Address option does not need to be
present in the received solicited Neighbor Advertisement to confirm
reachability. Therefore remove `tllao_offset` variable check from the
if condition responsible for updating cache entry. No further changes in
the logic are required because if TLLA option is missing,
`lladdr_changed` will be set to false, so no LL address will be updated.

Signed-off-by: Robert Lubos <[email protected]>
(cherry picked from commit 02c153c)
@zephyrbot zephyrbot added Backport Backport PR and backport failure issues area: Networking labels Feb 14, 2025
@fabiobaltieri fabiobaltieri added this to the v3.7.2 milestone Feb 17, 2025
@nashif nashif merged commit 7777585 into v3.7-branch Feb 21, 2025
29 of 30 checks passed
@nashif nashif deleted the backport-85673-to-v3.7-branch branch February 21, 2025 01:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: Networking Backport Backport PR and backport failure issues

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

7 participants