diff options
| author | Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> | 2025-08-12 12:53:30 +0530 |
|---|---|---|
| committer | Johannes Berg <johannes.berg@intel.com> | 2025-09-04 11:19:02 +0200 |
| commit | 36b75dcb1e25739a3a0975699208c98f4b55d012 (patch) | |
| tree | dc0e9ce813b153446f7305ff9783bbd43aafa140 /rust/helpers/mutex.c | |
| parent | cfb58d5fc964e7e008d8d64c8fa8e9e28e501bc6 (diff) | |
wifi: mac80211: consider links for validating SCAN_FLAG_AP in scan request during MLO
Commit 78a7a126dc5b ("wifi: mac80211: validate SCAN_FLAG_AP in scan request
during MLO") introduced a check that rejects scan requests if any link is
already beaconing. This works fine when all links share the same radio, but
breaks down in multi-radio setups.
Consider a scenario where a 2.4 GHz link is beaconing and a scan is
requested on a 5 GHz link, each backed by a different physical radio. The
current logic still blocks the scan, even though it should be allowed. As a
result, interface bring-up fails unnecessarily in valid configurations.
Fix this by checking whether the scan is being requested on the same
underlying radio as the beaconing link. Only reject the scan if it targets
a link that is already beaconing and the NL80211_FEATURE_AP_SCAN is not
set. This ensures correct behavior in multi-radio environments and avoids
false rejections.
Fixes: 78a7a126dc5b ("wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO")
Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Link: https://patch.msgid.link/20250812-fix_scan_ap_flag_requirement_during_mlo-v4-3-383ffb6da213@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'rust/helpers/mutex.c')
0 files changed, 0 insertions, 0 deletions
