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:-)
[1]: https://lore.kernel.org/linux-wireless/20250131152657.5606-1-v.shevtsov@xxxxxxxxxxxxxxxxx/
Alexander
