[PATCH wireless-next v2] wifi: mac80211: consider links for validating SCAN_FLAG_AP in scan request during MLO

[PATCH wireless-next v2] wifi: mac80211: consider links for validating SCAN_FLAG_AP in scan request during MLO

[Aditya Kumar Singh]

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 SCAN_FLAG_AP 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>
---
Changes in v2:
- Rebased on ToT after dependent changes got merged.
- Link to v1: https://lore.kernel.org/r/20250528-fix_scan_ap_flag_requirement_during_mlo-v1-1-35ac0e3a2f7b@oss.qualcomm.com
---
 net/mac80211/cfg.c | 38 ++++++++++++++++++++++++++++++++++----
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index e0dd0a8625c0151a6d5ebdf4e37f4e3bc257b340..75f86c33545ee0055a569dcc364d14e0bd8e62ca 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2901,6 +2901,10 @@ static int ieee80211_scan(struct wiphy *wiphy,
 			  struct cfg80211_scan_request *req)
 {
 	struct ieee80211_sub_if_data *sdata;
+	struct ieee80211_link_data *link;
+	struct ieee80211_channel *chan;
+	int radio_idx;
+	u8 link_id;
 
 	sdata = IEEE80211_WDEV_TO_SUB_IF(req->wdev);
 
@@ -2928,10 +2932,36 @@ static int ieee80211_scan(struct wiphy *wiphy,
 		 * the frames sent while scanning on other channel will be
 		 * lost)
 		 */
-		if (ieee80211_num_beaconing_links(sdata) &&
-		    (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
-		     !(req->flags & NL80211_SCAN_FLAG_AP)))
-			return -EOPNOTSUPP;
+		for (link_id = 0; link_id < IEEE80211_MLD_MAX_NUM_LINKS;
+		     link_id++) {
+			link = sdata_dereference(sdata->link[link_id], sdata);
+			if (!link)
+				continue;
+
+			/* if the link is not beaconing, ignore it */
+			if (!sdata_dereference(link->u.ap.beacon, sdata))
+				continue;
+
+			/* If we are here then at least one of the link is
+			 * beaconing and since radio level information is
+			 * not present or single underlying radio is present,
+			 * no point in checking further and hence return if
+			 * flag requirements are not met.
+			 */
+			if (wiphy->n_radio < 2 &&
+			    (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
+			     !(req->flags & NL80211_SCAN_FLAG_AP)))
+				return -EOPNOTSUPP;
+
+			chan = link->conf->chanreq.oper.chan;
+			radio_idx = cfg80211_get_radio_idx_by_chan(wiphy, chan);
+
+			if (ieee80211_is_radio_idx_in_scan_req(wiphy, req,
+							       radio_idx) &&
+			    (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
+			     !(req->flags & NL80211_SCAN_FLAG_AP)))
+				return -EOPNOTSUPP;
+		}
 		break;
 	case NL80211_IFTYPE_NAN:
 	default:

---
base-commit: 757259db79fc6054780e07bb284f768b01cf8fa9
change-id: 20250527-fix_scan_ap_flag_requirement_during_mlo-d9bce1b859a1

Re: [PATCH wireless-next v2] wifi: mac80211: consider links for validating SCAN_FLAG_AP in scan request during MLO

[Johannes Berg]

On Tue, 2025-06-24 at 14:25 +0530, Aditya Kumar Singh wrote:
> 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 SCAN_FLAG_AP is not set. This
> ensures correct behavior in multi-radio environments and avoids false
> rejections.
> 

This triggers a warning in ieee80211_is_radio_idx_in_scan_req() in hwsim
tests.

johannes