RE: [PATCH v4] mac80211: Drop the packets whose source or destination mac address is empty

[Ming Chen <Ming.Chen@watchguard.com>]

> -----Original Message-----
> From: Kalle Valo <kvalo@codeaurora.org>
> Sent: Tuesday, November 19, 2019 1:42 AM
> To: Ming Chen <Ming.Chen@watchguard.com>
> Cc: Toke Høiland-Jørgensen <toke@redhat.com>; Ming Chen
> <ming032217@gmail.com>; Johannes Berg <johannes@sipsolutions.net>;
> linux-wireless@vger.kernel.org
> Subject: Re: [PATCH v4] mac80211: Drop the packets whose source or
> destination mac address is empty
> 
> Ming Chen <Ming.Chen@watchguard.com> writes:
> 
> >> > Dropping this kind of error packet before it goes into the driver,
> >> > should be the right direction.
> >>
> >> So I still wonder why this happens from higher up in the stack. If
> >> there's a legitimate reason, maybe dropping the packet is not the
> >> right thing? And if there is *no* legitimate reason, maybe the packet
> >> should be dropped higher up in the stack instead?
> >>
> >> What kind of packets does this happen with?
> >
> > [Ming Chen] It should an ARP packet. I can see this kind of packet
> > before ARP table is complete. If so, how about dropping it in the
> > function of ieee80211_subif_start_xmit?
> 
> The question here is why are you seeing this but nobody else? Are you using
> some special protocol, do you have some changes in the kernel which cause
> this or what could explain this behaviour?
> 
[Ming Chen] I am not very familiar with the ARP processing in Linux Kernel, but I am sure I can see 
this kind of packets coming from the upper stack. I talked with the guys of this area of my company today, 
and they told me we didn't make any change on the ARP relevant processing.  
From my perspective, I think dropping this kind of packets is more or less reasonable. 
Anyway, I will make more investigation on how this kind of packets come into the driver. Thanks
> --
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp
> atches