[1/2] wifi: nl80211/cfg80211: Stop supporting cooked monitor

Unconditionally start to refuse creating cooked monitor interfaces to
phase them out.

There is no feature flag for drivers to opt-in for cooked monitor and
all known users are using/preferring the modern API since the hostapd
release 1.0 in May 2012.

Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de>
---
That's kind of brutal... But still seems to be the best way.

While we keep NL80211_MNTR_FLAG_COOK_FRAMES around to not break software
like hostapd from compiling, nl80211 will refuse anyone from using it.
Which includes drivers which still may be fine with this feature.

But adding a feature flag for that outdated feature, assign it to all
drivers without knowing if they really support that any longer seems to
be a no-go. And adding an opt-out feature for something we plan to
remove also feels off.

That way we may be able to remove NL80211_MNTR_FLAG_COOK_FRAMES in some
years...

If you think that's too hard, there is another way:
I first tried to just refuse setting the flag in mac80211, but that
triggered a warning in nl80211 when rdev_add_virtual_intf() got the
error after green-lightening the flags in nl80211_parse_mon_options().

So we could add some code in nl80211 suppressing the warning when
MONITOR_FLAG_COOK_FRAMES is set. That would open up drivers to refuse
cooperation when someone tries to use the flag.

Alexander

---
 include/net/cfg80211.h       | 2 +-
 include/uapi/linux/nl80211.h | 4 ++--
 net/wireless/nl80211.c       | 4 ++++
 3 files changed, 7 insertions(+), 3 deletions(-)

Alexander Wetzel wrote:
> I first tried to just refuse setting the flag in mac80211, but that
> triggered a warning in nl80211 when rdev_add_virtual_intf() got the
> error after green-lightening the flags in nl80211_parse_mon_options().
> 
> So we could add some code in nl80211 suppressing the warning when
> MONITOR_FLAG_COOK_FRAMES is set. That would open up drivers to refuse
> cooperation when someone tries to use the flag.

Is that the same WARNING which is being fixed at [1] or something new?

FWIW, I think the current series would not go to the stable trees (at
least there are no Fixes ot Cc: stable tags), while [1] should go there
to suppress the currently observed and triggerable WARNING regarding
setting the outdated cooked monitor mode mixed with some other modes.

[1]: https://lore.kernel.org/linux-wireless/20250131152657.5606-1-v.shevtsov@mt-integration.ru/

On Fri, 07. Feb 13:27, Alexander Wetzel wrote:
> On 07.02.25 11:37, Fedor Pchelkin wrote:
> > Alexander Wetzel wrote:
> > > I first tried to just refuse setting the flag in mac80211, but that
> > > triggered a warning in nl80211 when rdev_add_virtual_intf() got the
> > > error after green-lightening the flags in nl80211_parse_mon_options().
> > > 
> > > So we could add some code in nl80211 suppressing the warning when
> > > MONITOR_FLAG_COOK_FRAMES is set. That would open up drivers to refuse
> > > cooperation when someone tries to use the flag.
> > 
> > Is that the same WARNING which is being fixed at [1] or something new?
> > 
> 
> While the patch here also kind of solves the issue from [1] it's unrelated.
> The warning I mentioned above was a different one. But since it was caused
> by experimental code never published noting I would call "new".
> 
> I tried to explain that mac80211 - or any other driver using nl80211 - can't
> refuse the cooked monitor flag with the current API to explain the brutal
> handling of that in the patch here.
> (The flag check should be handled within nl80211_parse_mon_options(). But
> since the drivers have no way to signal cooked monitor support it can't be
> checked there by any reasonable means.)
> 
> Here the WARN() my patch triggered:
> 
>         wdev = rdev_add_virtual_intf(rdev,
>                              nla_data(info->attrs[NL80211_ATTR_IFNAME]),
>                                 NET_NAME_USER, type, &params);
>         if (WARN_ON(!wdev)) {
>                 nlmsg_free(msg);
>                 return -EPROTO;
> 
> My not published patch refused the flag when rdev_add_virtual_intf() was
> creating the interface with the flag.
> 
> With the feedback from Johannes - that only mac80211 ever used cooked
> monitor mode - the current patch seems to be the preferred way and we don't
> have to find a better - and for sure ugly - way to handle that.
> 
> 
> > FWIW, I think the current series would not go to the stable trees (at
> > least there are no Fixes ot Cc: stable tags), while [1] should go there
> > to suppress the currently observed and triggerable WARNING regarding
> > setting the outdated cooked monitor mode mixed with some other modes.
> > 
> 
> I also would not like to drop cooked monitor support for any stable kernel.
> While that would fix some monitor handling issues I see no real need to even
> fix these in the stable series.
> Messung up virtual monitor interfaces by a special order creating them or
> using suspend/resume is hardly something the users of them will care about.
> Or they would have told us that long ago:-)

Okay, thanks for clarifying!