From: Mahesh Bandewar <mah...@bandewar.net> Date: Wed, 16 Aug 2017 17:02:51 -0700
> From: Mahesh Bandewar <mahe...@google.com> > > If the ARP processing creates a neigh entry, it's immediately marked > as STALE without timer and stays that way in that state as long as > host do not send traffic to that neighbour. > > I observed this on hosts which are in IPv6 environment, where there is > very little to no IPv4 traffic and neigh-entries are stuck in STALE > mode. Ideally, the host should have PROBEd these neighbours before it > can send the first packet out. > > It happens as a result of following call sequence in an environment > where host is mostly quiet as far as IPv4 traffic but few connected > hosts/gateways are sending ARPs. > > arp_process() > neigh_event_ns() > neigh_lookup() > neigh_create() > neigh_alloc() > nud_state=NUD_NONE > neigh_update(nud_state=NUD_STALE) > > In the above scenario, the neighbour entry does not get a chance to get > PROBEd as subsequent call to neigh_update() marks this entry STALE. > This patch initializes the neigh-entry correctly if it was created as a > result of neigh_lookup instead of just updating it in neigh_event_ns() > right after creating it. > > Signed-off-by: Mahesh Bandewar <mahe...@google.com> Please provide, in the commit message, a list of events including an example packet exchange and timers firing which explains how this situation arises. Thank you.
