After a short network outage, the dst_entry is timed out and put
in DST_OBSOLETE_DEAD. We are in this code because arp reply comes
from this neighbour after network recovers. There is a potential
race condition that dst_entry is still in DST_OBSOLETE_DEAD.
With that, another neighbour lookup causes
On Thu, Jan 07, 2021 at 09:36:37PM -0500, Your Real Name wrote:
> On Tue, Jan 05, 2021 at 04:05:21PM -0800, David Miller wrote:
> >
> >
> > From: Tong Zhu
> > Date: Wed, 30 Dec 2020 17:54:23 -0500
> >
> > > In 4.x kernel a dst in DST_OBSOLETE_DEAD state is associated
> > > with loopback net_de
On Tue, Jan 05, 2021 at 04:05:21PM -0800, David Miller wrote:
>
>
> From: Tong Zhu
> Date: Wed, 30 Dec 2020 17:54:23 -0500
>
> > In 4.x kernel a dst in DST_OBSOLETE_DEAD state is associated
> > with loopback net_device and leads to loopback neighbour. It
> > leads to an ethernet header with al
From: Tong Zhu
Date: Wed, 30 Dec 2020 17:54:23 -0500
> In 4.x kernel a dst in DST_OBSOLETE_DEAD state is associated
> with loopback net_device and leads to loopback neighbour. It
> leads to an ethernet header with all zero addresses.
>
> A very troubling case is working with mac80211 and ath9k.
In 4.x kernel a dst in DST_OBSOLETE_DEAD state is associated
with loopback net_device and leads to loopback neighbour. It
leads to an ethernet header with all zero addresses.
A very troubling case is working with mac80211 and ath9k.
A packet with all zero source MAC address to mac80211 will
eventu
