RTM_NEWNEIGH

[Roy Marples]

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.

I have a patch for dhcpcd to use this (attached as well, needs my latest
fossil trunk, -current is too old).
The end result is that on NetBSD there are no longer any polls for state
- the kernel notifies every event change.
The only elephants left in the room are drivers that don't set IFF_UP
before LINK_STATE_UPi (hi sk(4)) and drivers which could set link state
but don't bother to (hi ppp(4)).

Comments, as always, are welcome.

Roy

[Manuel Bouyer]

[...]
The only elephants left in the room are drivers that don't set IFF_UP before
LINK_STATE_UPi (hi sk(4))

I don't understant this. IFF_UP should not be set by the driver; it's
externally set to ask the driver to start operations.
What's the problem with setting link state independantly from IFF_UP ?
sk(4) is probably not the only driver doing this; if the link state can
be polled independanly from packet reception (I guess all interfaces supporting
wake on lan, or shared with an IPMI management card will, or should, do this)

[Greg Troxel]

Post by Manuel Bouyer

[...]
The only elephants left in the room are drivers that don't set IFF_UP before
LINK_STATE_UPi (hi sk(4))

I don't understant this. IFF_UP should not be set by the driver; it's
externally set to ask the driver to start operations.
What's the problem with setting link state independantly from IFF_UP ?
sk(4) is probably not the only driver doing this; if the link state can
be polled independanly from packet reception (I guess all interfaces supporting
wake on lan, or shared with an IPMI management card will, or should, do this)

But if the interface is not UP, then the driver should not be enabling
the PHY and there should be no way to get positive link status.

Still, it seems unnecessary for userland to get upset about link state
already being up when bringing an interface up. I guess the point is
that

assume link state is down because !IFF_UP

ifconfig foo0 up

assume that tracking up/down notifications leads to understanding the state

doesn't really work. Obvious fixes would seem to be poll once after
bringing up, and having drivers send a notify of current state
immediately on being brought up. Or sending a positive link indication
if already up when bring brought up, which seems easy and probably
broadly helpful.

[Manuel Bouyer]

Post by Greg Troxel
But if the interface is not UP, then the driver should not be enabling
the PHY and there should be no way to get positive link status.

If you don't enable the PHY, wake on lan and IPMI won't work.

[Greg Troxel]

Post by Roy Marples
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.

But I don't object. The don't-poll point is valid.

[Roy Marples]

Post by Greg Troxel
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.

It's about tracking the state change for managing router selection in
userland based on reachability.

Post by Greg Troxel
But I don't object. The don't-poll point is valid.

Roy

[David Young]

Post by Greg Troxel

Post by Roy Marples
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.

Dave

[Roy Marples]

Post by David Young

Post by Greg Troxel

Post by Roy Marples
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.

Would this patch be preferable? I'm guessing yes it would.
Comments welcome.

Roy

[Greg Troxel]

Post by Roy Marples

Post by David Young

Post by Greg Troxel
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!

What I meant was "why don't you send RTM_ADD instead of creating a new
message type". Sorry if that was unclear.

Post by Roy Marples
* 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.
Would this patch be preferable? I'm guessing yes it would.
Comments welcome.

Yes, this seem good to me.

[David Young]

Post by Greg Troxel

Post by Roy Marples

Post by David Young

Post by Greg Troxel
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!

What I meant was "why don't you send RTM_ADD instead of creating a new
message type". Sorry if that was unclear.

That's what I meant, too. Sorry for being ambiguous!

Post by Greg Troxel

Post by Roy Marples
* RTM_ADD for new neighbour cache entry
* RTM_CHANGE for an updated cache entry
* RTM_DEL for a deleted neighbour cache entry

Sounds good to me.

Dave

[Roy Marples]

Post by Roy Marples

Post by David Young

Post by Greg Troxel

Post by Roy Marples
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!
* 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.

dhcpcd-6.6.6 is now in -current which now uses this.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de