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