[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RTM_MISS vs RTM_DELETE
On 01/09/2019 21:42, Roy Marples wrote:
On 31/08/2019 04:50, Roy Marples wrote:
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
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.
Main Index |
Thread Index |