Page MenuHomeFreeBSD

Set the correct state for new neighbor cache entries

Authored by vangyzen on Jan 26 2018, 5:11 PM.
Referenced Files
Unknown Object (File)
Tue, Dec 5, 3:25 PM
Unknown Object (File)
Wed, Nov 29, 3:22 AM
Unknown Object (File)
Wed, Nov 29, 3:14 AM
Unknown Object (File)
Tue, Nov 28, 5:10 AM
Unknown Object (File)
Sat, Nov 25, 4:09 AM
Unknown Object (File)
Wed, Nov 22, 4:07 PM
Unknown Object (File)
Mon, Nov 13, 5:26 PM
Unknown Object (File)
Mon, Nov 13, 4:36 AM



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

rS FreeBSD src repository - subversion
Lint Not Applicable
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.