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, ¶ms);
> 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!
