From: Mathy Vanhoef <Mathy.Vanhoef@kuleuven.be>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] mac80211: keep non-zero sequence counter of injected frames
Date: Wed, 1 Jul 2020 11:32:57 +0400 [thread overview]
Message-ID: <20200701113257.28af0012@mathy-work.localhost> (raw)
In-Reply-To: <a814fe75135815e85a1968cf6a985c604246bcc8.camel@sipsolutions.net>
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 <johannes@sipsolutions.net> 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
>
next prev parent reply other threads:[~2020-07-01 7:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-28 18:05 [PATCH] mac80211: keep non-zero sequence counter of injected frames Mathy Vanhoef
2020-06-28 18:59 ` Johannes Berg
2020-07-01 7:32 ` Mathy Vanhoef [this message]
2020-06-29 9:38 ` kernel test robot
2020-06-29 11:19 ` kernel test robot
2020-06-29 12:30 ` kernel test robot
2020-07-07 13:45 ` Dan Carpenter
2020-07-07 13:55 ` Mathy Vanhoef
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200701113257.28af0012@mathy-work.localhost \
--to=mathy.vanhoef@kuleuven.be \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox