On 14/12/2014 22:23, David Young wrote:
On Thu, Dec 11, 2014 at 12:57:58PM -0500, Greg Troxel wrote:
dhcpcd polls SIOCGNBRINFO_IN6 every second for every IPv6 router it
knows about to test neighbour reach-ability.
This isn't exactly optimal, hello battery drain.
Attached is a patch to add RTM_NEWNEIGH so that userland can react
to
Neighbour Discovery changes, similar to the Linux equivalent.
It's designed to be protocol agnostic, (ie could be used for ARP as
well).
Currently, it only raises RTM_NEWNEIGH on IPv6 neighbour state and
flag (is it a router?) changes.
There is little point in generating RTM_DELNEIGH or RTM_GETNEIGH as
Linux does because our current
implementation sends equivalent messages via RTM_DELETE or
RTM_CHANGE.
Why doesn't RTM_ADD get sent for ND entries in the table? I don't
see
why a new message is needed. Or is this about some later state
transition from them just being added, because the later transition
is
what matters.
I'd also like to know why RTM_ADD isn't sent for the new neighbors.
Because there is no code to notify userland!
Here is a new patch where all route changes are notified to userland:
* RTM_ADD for new neighbour cache entry
* RTM_CHANGE for an updated cache entry
* RTM_DEL for a deleted neighbour cache entry
Using this I can then detect host route additions/changes/deletions and
take action in dhcpcd accordingly. After all, I only care if I can
reach
the router or not, I don't care about the neighbour state as such.