Re: [lvc-project] [PATCH] wifi: nl80211: override all other flags if MONITOR_FLAG_COOK_FRAMES is set

[Johannes Berg]

On Mon, 2025-02-03 at 12:40 +0200, Jouni Malinen wrote:
> On Thu, Jan 30, 2025 at 10:13:14PM +0100, Johannes Berg wrote:
> > On Thu, 2025-01-30 at 22:23 +0300, Fedor Pchelkin wrote:
> > > Wouldn't it break existing userspace, especially in context of systems
> > > running old stable kernels where the patch is also needed?
> > > 
> > > There is still some usage of this flag in hostap [1].
> > 
> > Theoretically, but I just commented on that here:
> > 
> > https://lore.kernel.org/r/a49e58998553c45953a30243ad1957c06ce6db8c.camel@xxxxxxxxxxxxxxxx
> > 
> > tl;dr: only ancient hostapd versions will actually _use_ it, and they
> > have to fall into a relatively narrow range (April 2009 - Dec 2011.)
> 
> How did you determine that commit a11241fa1149 ("nl80211: Use nl80211
> for mgmt TX/RX in AP mode") ends this use? Support for monitor mode
> interface is still in hostap.git and it is even tested as part of the
> hwsim test cases.. Both hostapd and wpa_supplicant can still be
> configured to use the monitor interface.

Well, fair, there are perhaps certain explicit configurations where you
get monitor support, but by default as of that commit it should be
selecting the nl80211 path.

Though looking further, I suppose that in practice commit 73a3c6ffca0c
("nl80211: Use the monitor interface if socket tx status is not
supported") moves the date out a bit, albeit not related to upstream
kernels but only wifi backports to earlier upstream kernels.

> It would be another question to ask whether there is any good reason to
> use this anymore now that a better approach has been available for 13
> years and the answer to that is likely "no". Anyway, this is a kernel
> interface that has a user even in the current snapshot of user space
> programs. If we are about to break that use, it would make sense to
> first remove such users. I don't think I would really care about this
> anymore and it would be nice to get rid of all that unlikely to be used
> much, if at all, code.

Right.

> Though, this seems to imply that the case used by hostapd/wpa_supplicant
> would not be broken.

Not for this patch, no, but I did float the idea of removing it all
entirely.

johannes