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

[PATCH wireless-next v3] 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 v3:
- Rebased on ToT.
- Fixed hwsim warning issues. 
- Link to v2: https://lore.kernel.org/r/20250624-fix_scan_ap_flag_requirement_during_mlo-v2-1-c8067d0ee1f0@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 | 41 +++++++++++++++++++++++++++++++++++++----
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 56540c3701ed786c37f946f9c4af820c15b5922d..290ae4ef02f5097a7efb7e4b9d3f846fc672679b 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2919,6 +2919,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);
 
@@ -2946,10 +2950,39 @@ 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) {
+				if (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
+				    !(req->flags & NL80211_SCAN_FLAG_AP))
+					return -EOPNOTSUPP;
+
+				continue;
+			}
+
+			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: 7322a7d80c48f81888414f347e88ebd4e49f7f56
change-id: 20250527-fix_scan_ap_flag_requirement_during_mlo-d9bce1b859a1

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

[Johannes Berg]

On Wed, 2025-06-25 at 18:31 +0530, Aditya Kumar Singh wrote:
> 
> -		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;

for_each_link_data()

> +
> +			/* 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) {
> +				if (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
> +				    !(req->flags & NL80211_SCAN_FLAG_AP))
> +					return -EOPNOTSUPP;
> +
> +				continue;
> +			}

Is that _really_ worth special-casing in the scan control path? It's not
like this is a performance question here.

Maybe ieee80211_is_radio_idx_in_scan_req() shouldn't WARN_ON() then or
something, so we can reuse it. Or maybe (better?) just reorder the
checks there, if the chan_radio_idx==-1 and radio_idx==-1 would return
first, and WARN only if we found a scan channel that isn't covered by a
radio?

And <2 seems really strange anyway, ==1 should basically never happen,
it's equivalent to ==0, as in no list of radios?

johannes

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

[Aditya Kumar Singh]

On 7/8/2025 4:16 PM, Johannes Berg wrote:
> On Wed, 2025-06-25 at 18:31 +0530, Aditya Kumar Singh wrote:
>>
>> -		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;
> 
> for_each_link_data()

Sure. When I was writing this, this macro was not present hence did not 
use it. Now that it is there, I will use it. Thanks for pointing it out.

> 
>> +
>> +			/* 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) {
>> +				if (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
>> +				    !(req->flags & NL80211_SCAN_FLAG_AP))
>> +					return -EOPNOTSUPP;
>> +
>> +				continue;
>> +			}
> 
> Is that _really_ worth special-casing in the scan control path? It's not
> like this is a performance question here.
> 
> Maybe ieee80211_is_radio_idx_in_scan_req() shouldn't WARN_ON() then or
> something, so we can reuse it. Or maybe (better?) just reorder the
> checks there, if the chan_radio_idx==-1 and radio_idx==-1 would return
> first, and WARN only if we found a scan channel that isn't covered by a
> radio?

sure reordering seems much better. Thanks for the suggestion, will change.

> 
> And <2 seems really strange anyway, ==1 should basically never happen,
> it's equivalent to ==0, as in no list of radios?

That is correct. If underlying wiphy does not advertise, it would be 0. 
And if it advertises, ideally it should be 2 or more (otherwise why 
advertising?) But, there is no check for 1. So a radio can choose to 
advertise but keep n_radios as 1. And having n_radio 1 is also same as 
not advertising it. Hence to ensure these kicks in only when we know 
n_radios is greater than 1, < 2 is checked. Same way other two places 
also it is used.


-- 
Aditya