Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <e49a74513f287a1343067f51335570094ae2edae.camel@sipsolutions.net>
Subject: Re: [PATCH v4] mac80211: Drop the packets whose source or
 destination mac address is empty
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= <toke@redhat.com>,
        Ming Chen <ming032217@gmail.com>
Cc:     linux-wireless@vger.kernel.org,
        Ming Chen <ming.chen@watchguard.com>
Date:   Mon, 18 Nov 2019 13:15:33 +0100
In-Reply-To: <87blt9ctd4.fsf@toke.dk>
References: <20191116060833.45752-1-ming.chen@watchguard.com>
         <87blt9ctd4.fsf@toke.dk>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Mon, 2019-11-18 at 12:32 +0100, Toke Høiland-Jørgensen wrote:

> > 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?

Agree, this is really weird, it'd be good to know the actual packet this
happens with. Don't think I've ever seen this.

johannes