Page MenuHomeFreeBSD

Set the correct state for new neighbor cache entries
ClosedPublic

Authored by vangyzen on Jan 26 2018, 5:11 PM.
Tags
None
Referenced Files
F78454844: D14059.diff
Sun, Mar 3, 2:56 PM
Unknown Object (File)
Jan 15 2024, 2:27 PM
Unknown Object (File)
Jan 12 2024, 10:06 AM
Unknown Object (File)
Dec 20 2023, 6:32 AM
Unknown Object (File)
Dec 5 2023, 3:25 PM
Unknown Object (File)
Nov 29 2023, 3:22 AM
Unknown Object (File)
Nov 29 2023, 3:14 AM
Unknown Object (File)
Nov 28 2023, 5:10 AM

Details

Summary

Restore state 6. Many of the UNH tests end up exercising this
state, where we have a new neighbor cache entry and a new link-layer
entry is being created for it. The link-layer address is currently
unknown so the initial state of the "llentry" should remain initialized
to ND6_LLINFO_NOSTATE so that the ND code will send a solicitation.
Setting this to ND6_LLINFO_STALE implies that the link-level entry
is valid and can be used (but needs to be refreshed via the Neighbor
Unreachability state machine).

Test Plan

Several UNH IPv6 conformance tests failed before this change
and passed after the change.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

mjoras added a subscriber: mjoras.

Thanks for this. I've noticed this behavior when debugging an unrelated ND6 issue, but never dug into where it happens in the code.

This revision is now accepted and ready to land.Jan 26 2018, 5:24 PM
dab added a reviewer: dab.

@ae, would you like to review this?

This revision was automatically updated to reflect the committed changes.