Re: [PATCH v4] wifi: mac80211: fix monitor mode frame capture for real chanctx drivers
From: Óscar Alfonso Díaz
Date: Wed May 20 2026 - 05:51:54 EST
Ok, let me do one final test using Johannes’ v2 patch. The expected
behavior is as follows:
6.18 or lower: no need to test, it will not work. It’s clear now that
this does not matter, since the goal is only to fix newer kernel
versions.
6.19: some versions of the 6.19 will crash and others will not. The
crash was fixed at some point between 6.18.12 and 6.19.12. No need to
test.
7.0, or 7.1: the expected result is that there will be no crash, and
VIF + deauth will work only on 2.4 GHz. It will not work on 5 GHz
(I'll test both, normal DoS and VIF+DoS). There should be no crash,
but it will not work.
So I'll focus my testing on 7.0 and 7.1 and I'll get back to you with
the results. I'll be testing this patch (v2):
https://patchwork.kernel.org/project/linux-wireless/patch/20251216111909.25076-2-johannes@xxxxxxxxxxxxxxxx/
Give me some time to do these tests. I'll test it on both 7.0 and 7.1 kernels.
Thanks and regards.
--
Oscar
OpenPGP Key: DA9C60E9 ||
https://pgp.mit.edu/pks/lookup?op=get&search=0x79B17260DA9C60E9
4F74 B302 354D 817D DE38 0A43 79B1 7260 DA9C 60E9
--
El mié, 20 may 2026 a las 10:58, Johannes Berg
(<johannes@xxxxxxxxxxxxxxxx>) escribió:
>
> On Wed, 2026-05-20 at 10:02 +0200, Óscar Alfonso Díaz wrote:
> > I tested it on 6.18.12
> >
> > Let me know if you need me to test it again or whatever. I remember
> > during my testing with the Brite's different patches that is not the
> > same testing it on 6.18.x than 6.19 . Some stuff changed and the patch
> > needed to be different. I've added Brite to the thread, he can add
> > more useful data for you.
>
> I guess I don't really care about 6.18.x or 6.19.x, only about 7.1-rcX
> at this point. We'll want to explicitly _not_ backport this fix to older
> kernel versions since it caused driver crashes.
>
> > Regarding the approach of fixing the bug on the driver side... I've
> > emailed and contacted by IRC to Lorenzo explaining the problem... but
> > I got no response. So if we feel yet like this is something that needs
> > to be fixed from the "driver side"... how to say it softly... we are
> > f***ed up :) . Maybe the "hack" way dealing with the vif null var is
> > not bad idea after all as it seems the only way to move forward.
>
> I feel I've tried to say this before, but maybe it helps if I summarise:
>
> There's one feature and one (possible) bug here.
>
> The feature is:
> - monitor mode injection works for chanctx drivers.
>
> The bug is:
> - monitor mode injection with the feature patch crashes at least some
> mt76 devices, which you reported, which I consider to be a bug in the
> driver that needs to be fixed there.
>
> To me, the trade-off is crystal clear - as long as the bug exists, I'm
> not going to apply this or a similar patch to enable the feature.
>
> I'm also not going to apply a patch like proposed before that hacks it
> by redirecting the vif pointer to a (more or less random) other vif,
> that's a lazy hack that happens to fix the problem in your _specific_
> use case, but will almost certainly still expose the crash in other use
> cases.
>
> I do think there's a chance that between 6.18/6.19 and 7.1-rcX the bug
> in the driver has already been fixed, that's why I keep asking about
> versions etc. But I also think there's a chance you're just testing
> different subdrivers of mt76 with different devices, so I'm also asking
> you to compare the specific devices.
>
> I'm happy to apply this patch if the people who previously reported it
> to crash (i.e. mostly you, not sure about others) are saying that
> against a more recent kernel it no longer causes the test to crash
> (rather than just not work, which is clearly better than crashing.)
>
> You could always just claim you've tested this patch without the crash
> and I'll apply it, but then if someone still finds a crash I'm just
> going to have to revert it, and we'd be back to square one.
>
> I hope this explains what I'm thinking and going to do (and not do),
> make of it what you will.
>
> johannes