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
Unknown Object (File)
Sun, Nov 3, 1:13 PM
Unknown Object (File)
Sun, Nov 3, 1:13 PM
Unknown Object (File)
Sat, Nov 2, 3:26 PM
Unknown Object (File)
Sat, Nov 2, 3:09 PM
Unknown Object (File)
Fri, Nov 1, 2:55 PM
Unknown Object (File)
Fri, Nov 1, 2:54 PM
Unknown Object (File)
Fri, Nov 1, 2:54 PM
Unknown Object (File)
Fri, Nov 1, 2:47 PM

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.