On 1/18/24 16:46, Johannes Berg wrote:
On Wed, 2024-01-17 at 15:48 +0300, Dmitry Antipov wrote:
If we're scanning and got the control frame with zero rate mask, drop
the frame before '__rate_control_send_low()' getting stuck attempting
to select supported rate.
But why drop the frame? I'm still thinking that it just doesn't really
make sense to apply the rate mask to scanning at all?
Hm. It seems that I'm still missing something important, but I don't
realize why ieee80211_scan_state_set_channel() advances to the (next)
channel even after ieee80211_set_bitrate_mask() resets this channel's
rate mask to 0. Note that the comment in ieee80211_set_bitrate_mask()
explicitly states that there should be at least one usable rate for
the band we're currently operating on. Why this is not applicable to
other band(s) we might probe next?
The most common use case for this is probably P2P-style things where you
just don't want to use CCK, but for scanning we have
NL80211_ATTR_TX_NO_CCK_RATE for this, so there's really no need to apply
the rate mask?
Does NL80211_ATTR_TX_NO_CCK_RATE makes an effect on bands other than
2.4GHz? Note original reproducer triggers WARN_ONCE() after switching
to 5GHz.
Dmitry
