[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
RTM_MISS vs RTM_DELETE
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.
Main Index |
Thread Index |