RTM_MISS vs RTM_DELETE

[Roy Marples]

dhcpcd wants to know if a router is unreachable.
Not so it can drop the default route, but so it can start solicitations
for a new router.

History.
BSD has always announced RTM_ADD for a cloned route with an empty gateway.
I added the symetry for RTM_CHANGE (lladdr was entered or changed) and
RTM_DELETE (cloned route deleted) in NetBSD-7.

NetBSD-8 removed the notion of cloned routes and also lost the above
symetry I added. I sure didn't notice until recently.
I've recently added fixes for this and submitted PR's for -9.

But I'm now wondering if this is the correct thing to do.
Now that we no longer have cloned routes, RTM_ADD/CHANGE/DELETE is
purely an implementation detail.
Infact, rtsock.c r 1.215 added back the announcement of the route,
requested by ryo@ - I have to ask why as it only says "i intend to
resolve" but ignores the important outcome.

RTM_MISS is send when the destination cannot be resolved.
IF it has already been resolved but the address is not currently
resolvable then RTM_MISS is not sent. I don't see how this is done, but
it seems to be an artifact of ARP as those entries don't expire.

So my question is this - should we remove RTM_ADD/CHANGE/DELETE for the
no-longer cloned routes and fix RTM_MISS to always be reportable?

Pro: it would reduce route(4) messages and fix the intent
Con: it would break compat with -7 (but already broken in -8 so who cares?)

dhcpcd pro: We don't really care if a node is no longer reachable - we
only care if, we want to use it and it's not available so from this
biased perspective it makes sense to fix RTM_MISS.

Sorry for the huge wall of text, but I'd like to get this sorted before -9.

Roy

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

[Roy Marples]

Post by Roy Marples
So my question is this - should we remove RTM_ADD/CHANGE/DELETE for the
no-longer cloned routes and fix RTM_MISS to always be reportable?

I thought about this a lot and have now comitted fixes and submitted
PR's for -9.
Here's the commit details if too lazy to read source-changes@

inet6: Send RTM_MISS when we fail to resolve an address.

Takes the same approach as when adding a new address - we no longer
announce the new lladdr right away but we announce the result.
This will either be RTM_ADD or RTM_MISS.
RTM_DELETE is only sent if we have a lladdr assigned OR gc'ed.

This results in less messages via route(4) and tells us when a new
lladdr has been added (RTM_ADD), changed (RTM_CHANGE), deleted (RTM_DELETED)
or has failed to been resolved (RTM_MISS). The latter case can be
interpreted as unreachable.

While looking over the code I also made this change:

inet6: Re-introduce ND6_LLINFO_WAITDELETE so we can return EHOSTDOWN

Once we've sent nd6_mmaxtries NS messages, send RTM_MISS and move to the
ND6_LLINFO_WAITDELETE state rather than freeing the llentry right away.
Wait for a probe cycle and then free the llentry.

If a connection attempts to re-use the llentry during ND6_LLINFO_WAITDELETE,
return EHOSTDOWN (or EHOSTUNREACH if a gateway) to match inet behaviour.
Continue to ND6_LLINFO_INCOMPLETE and send another NS probe in hope of a
reply. Rinse and repeat.

This reverts part of nd6.c r1.14 - an 18 year old commit!

Roy

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

[Roy Marples]

Post by Roy Marples
inet6: Re-introduce ND6_LLINFO_WAITDELETE so we can return EHOSTDOWN
Once we've sent nd6_mmaxtries NS messages, send RTM_MISS and move to the
ND6_LLINFO_WAITDELETE state rather than freeing the llentry right away.
Wait for a probe cycle and then free the llentry.
If a connection attempts to re-use the llentry during
ND6_LLINFO_WAITDELETE,
return EHOSTDOWN (or EHOSTUNREACH if a gateway) to match inet behaviour.
Continue to ND6_LLINFO_INCOMPLETE and send another NS probe in hope of a
reply. Rinse and repeat.
This reverts part of nd6.c r1.14 - an 18 year old commit!

For example, ping6 output is now like this:

$ ping6 fd73:7808:1015::1f8
PING6(56=40+8+8 bytes) fd73:7808:1015::1f7 --> fd73:7808:1015::1f8
ping6: sendmsg: Host is down
ping6: wrote fd73:7808:1015::1f8 16 chars, ret=-1
ping6: sendmsg: Host is down
ping6: wrote fd73:7808:1015::1f8 16 chars, ret=-1
ping6: sendmsg: Host is down
ping6: wrote fd73:7808:1015::1f8 16 chars, ret=-1
^C
--- fd73:7808:1015::1f8 ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

Which now matches ping an unreachable inet address.

Roy

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

[Roy Marples]

Post by Roy Marples

Post by Roy Marples
So my question is this - should we remove RTM_ADD/CHANGE/DELETE for
the no-longer cloned routes and fix RTM_MISS to always be reportable?

I thought about this a lot and have now comitted fixes and submitted
PR's for -9.
inet6: Send RTM_MISS when we fail to resolve an address.
Takes the same approach as when adding a new address - we no longer
announce the new lladdr right away but we announce the result.
This will either be RTM_ADD or RTM_MISS.
RTM_DELETE is only sent if we have a lladdr assigned OR gc'ed.
This results in less messages via route(4) and tells us when a new
lladdr has been added (RTM_ADD), changed (RTM_CHANGE), deleted
(RTM_DELETED)
or has failed to been resolved (RTM_MISS). The latter case can be
interpreted as unreachable.

Made a similar change to inet, so aside from the differing timers the
flow is the same.

Roy

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

[David Young]

Post by Roy Marples
dhcpcd wants to know if a router is unreachable.
Not so it can drop the default route, but so it can start
solicitations for a new router.

dhcpcd is not the only daemon that reads the routing socket. Does
anybody test NetBSD with routing daemons like Quagga (or whatever it's
called now) and BIRD?

Dave