From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9D63C433E0 for ; Wed, 1 Jul 2020 07:33:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8E881206A1 for ; Wed, 1 Jul 2020 07:33:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728203AbgGAHdJ (ORCPT ); Wed, 1 Jul 2020 03:33:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728146AbgGAHdJ (ORCPT ); Wed, 1 Jul 2020 03:33:09 -0400 Received: from rhcavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 247E1C061755 for ; Wed, 1 Jul 2020 00:33:09 -0700 (PDT) X-KULeuven-Envelope-From: mathy.vanhoef@kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: C9718120346.A005C X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by rhcavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id C9718120346 for ; Wed, 1 Jul 2020 09:33:01 +0200 (CEST) Received: from mathy-work.localhost (unknown [176.205.50.14]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTPSA id 0F174200A1; Wed, 1 Jul 2020 09:33:00 +0200 (CEST) Date: Wed, 1 Jul 2020 11:32:57 +0400 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Mathy Vanhoef To: Johannes Berg Cc: Subject: Re: [PATCH] mac80211: keep non-zero sequence counter of injected frames Message-ID: <20200701113257.28af0012@mathy-work.localhost> In-Reply-To: References: <20200628220512.28535ebc@mathy-work.localhost> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org The kernel test robot highlighted a bug in the patch. So for now do not apply this one. I'm currently testing the injection behavior of some new devices I have, since my current ones are getting old, and I'll send updated patches within a week or two if all goes well. On Sun, 28 Jun 2020 20:59:56 +0200 Johannes Berg wrote: > On Sun, 2020-06-28 at 22:05 +0400, Mathy Vanhoef wrote: > > The sequence number of injected frames is being overwritten by the > > function ieee80211_tx_h_sequence when the following two conditions > > are met: > > > > 1. The frame is injected on a virtual interface, and a second > > virtual interface on this device is operating in managed/AP/.. mode. > > > > 2. The sender MAC address of the injected frame matches the MAC > > address of the second interface operating in managed/AP/.. mode. > > > > In some cases this may be desired, for instance when hostap is > > configured to send certain frames using a monitor interface, in > > which case the user-space will not assign a sequence number and > > instead injects frames with a sequence number of zero. > > Yeah, this is where that used to be used. I'm thinking we should > "break" this stuff eventually, tell people to use modern hostapd > versions, and see who cares ... because all this "cooked monitor" > etc. is all quite ugly. > > > However, in case the user-space does assign a non-zero sequence > > number, this number should not be overwritten by the kernel. This > > patch adds a check to see if injected frames have already been > > assigned a non-zero sequence number, and if so, this sequence > > number will not be overwritten by the kernel. > > Seems reasonable, but I have to wonder what you're up to now ;-) > > Anyway, I'll apply this unless I find some tests fail or something, > but I'll be going on vacation soon, so it'll be a while (since it's > for the -next tree as a feature). > > johannes >