tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


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.

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.


Home | Main Index | Thread Index | Old Index