[PATCH wireless-next 0/2] wifi: mac80211: some bug fixes in MLO scan handling

[PATCH wireless-next 0/2] wifi: mac80211: some bug fixes in MLO scan handling

[Aditya Kumar Singh]

This series addresses issues related to MLO handling in probe response
acceptance and scan request validation.

* Validate SCAN_FLAG_AP in scan request during MLO:
	Enforce the requirement for the NL80211_SCAN_FLAG_AP flag in scan
	requests when an AP interface is beaconing.

	Apply this restriction to ML interfaces by using the existing
	helper ieee80211_num_beaconing_links() to check if any link is
	beaconing.

* Accept probe response on link address as well:
	Ensure unicast probe response frames are accepted if the
	destination address matches any of the link addresses when a
	random MAC address is not requested.

	This change corrects the behavior where probe response frames are
	dropped incorrectly for MLO interfaces.

Both the changes are as such independent from each other. Since both are
related to MLO scanning, currently kept in same series.

---
Aditya Kumar Singh (2):
      wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO
      wifi: mac80211: accept probe response on link address as well

 net/mac80211/cfg.c  |  3 ++-
 net/mac80211/scan.c | 18 +++++++++++++++++-
 2 files changed, 19 insertions(+), 2 deletions(-)
---
base-commit: 63a9a727d373fa5b8ce509eef50dbc45e0f745b9
change-id: 20250402-bug_fix_mlo_scan-fe57f57b1c86

[PATCH wireless-next 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO

[Aditya Kumar Singh]

When an AP interface is already beaconing, a subsequent scan is not allowed
unless the user space explicitly sets the flag NL80211_SCAN_FLAG_AP in the
scan request. If this flag is not set, the scan request will be returned
with the error code -EOPNOTSUPP. However, this restriction currently
applies only to non-ML interfaces. For ML interfaces, scans are allowed
without this flag being explicitly set by the user space which is wrong.
This is because the beaconing check currently uses only the deflink, which
does not get set during MLO.

Hence to fix this, during MLO, use the existing helper
ieee80211_num_beaconing_links() to know if any of the link is beaconing.

Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
---
 net/mac80211/cfg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 2cd8731d8275b2f67c1b1305ec0bafc368a4498a..9da2c9398c855b9c6f40a234469f21dd361e486b 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2924,7 +2924,8 @@ static int ieee80211_scan(struct wiphy *wiphy,
 		 * the frames sent while scanning on other channel will be
 		 * lost)
 		 */
-		if (sdata->deflink.u.ap.beacon &&
+		if ((sdata->deflink.u.ap.beacon ||
+		     ieee80211_num_beaconing_links(sdata)) &&
 		    (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
 		     !(req->flags & NL80211_SCAN_FLAG_AP)))
 			return -EOPNOTSUPP;

-- 
2.34.1

Re: [PATCH wireless-next 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO

[Johannes Berg]

On Tue, 2025-05-13 at 09:26 +0530, Aditya Kumar Singh wrote:
> 
> -		if (sdata->deflink.u.ap.beacon &&
> +		if ((sdata->deflink.u.ap.beacon ||
> +		     ieee80211_num_beaconing_links(sdata)) &&
> 

Do we even still need the deflink check? Seems like
num_beaconing_links() _should_ return 1 anyway even though it currently
doesn't, and we need to fix that?

Also seems the VLAN carrier handling is broken.

johannes

Re: [PATCH wireless-next 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO

[Aditya Kumar Singh]

On 5/13/2025 12:47 PM, Johannes Berg wrote:
> On Tue, 2025-05-13 at 09:26 +0530, Aditya Kumar Singh wrote:
>>
>> -		if (sdata->deflink.u.ap.beacon &&
>> +		if ((sdata->deflink.u.ap.beacon ||
>> +		     ieee80211_num_beaconing_links(sdata)) &&
>>
> 
> Do we even still need the deflink check? Seems like
> num_beaconing_links() _should_ return 1 anyway even though it currently
> doesn't, and we need to fix that?

If the ieee80211_num_beaconing_links() is modified then deflink check is 
not required. Do you want to me to send a clean up for that function 
first or would take this and later the clean up part?

> 
> Also seems the VLAN carrier handling is broken.
With this patch? Or in general you are saying? HWSIM test cases seems to 
be working fine for me with this series applied. May be there is no test 
case to make it evident?

-- 
Aditya

Re: [PATCH wireless-next 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO

[Johannes Berg]

On Tue, 2025-05-13 at 15:47 +0530, Aditya Kumar Singh wrote:
> On 5/13/2025 12:47 PM, Johannes Berg wrote:
> > On Tue, 2025-05-13 at 09:26 +0530, Aditya Kumar Singh wrote:
> > > 
> > > -		if (sdata->deflink.u.ap.beacon &&
> > > +		if ((sdata->deflink.u.ap.beacon ||
> > > +		     ieee80211_num_beaconing_links(sdata)) &&
> > > 
> > 
> > Do we even still need the deflink check? Seems like
> > num_beaconing_links() _should_ return 1 anyway even though it currently
> > doesn't, and we need to fix that?
> 
> If the ieee80211_num_beaconing_links() is modified then deflink check is 
> not required. Do you want to me to send a clean up for that function 
> first or would take this and later the clean up part?

Given that you're targeting wireless-next for all, I guess I'd prefer
you clean up ieee80211_num_beaconing_links() first? But no strong
preferences.

> > Also seems the VLAN carrier handling is broken.
> With this patch? Or in general you are saying? HWSIM test cases seems to 
> be working fine for me with this series applied. May be there is no test 
> case to make it evident?

Oh, I meant in general.

So here I looked at callers of ieee80211_num_beaconing_links(), and many
of them seemed wrong because it doesn't handle non-MLO? But now that I
look again, I'm actually wrong, it simply always returns 0 for non-MLO,
but the comparisons are for <=1 which makes that ... OK but unexpected I
guess.


But still - also unrelated to this patch - the VLAN handling here seems
wrong?

        if (ieee80211_num_beaconing_links(sdata) <= 1)
                netif_carrier_on(dev);

        list_for_each_entry(vlan, &sdata->u.ap.vlans, u.vlan.list)
                netif_carrier_on(vlan->dev);

Shouldn't that loop be inside the ieee80211_num_beaconing_links() if?
Also on the netif_carrier_off() side? At least someone was fixing VLAN
vs. MLO recently, so maybe that needs fixes too.

johannes

Re: [PATCH wireless-next 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO

[Aditya Kumar Singh]

On 5/13/2025 3:51 PM, Johannes Berg wrote:
> On Tue, 2025-05-13 at 15:47 +0530, Aditya Kumar Singh wrote:
>> On 5/13/2025 12:47 PM, Johannes Berg wrote:
>>> On Tue, 2025-05-13 at 09:26 +0530, Aditya Kumar Singh wrote:
>>>>
>>>> -		if (sdata->deflink.u.ap.beacon &&
>>>> +		if ((sdata->deflink.u.ap.beacon ||
>>>> +		     ieee80211_num_beaconing_links(sdata)) &&
>>>>
>>>
>>> Do we even still need the deflink check? Seems like
>>> num_beaconing_links() _should_ return 1 anyway even though it currently
>>> doesn't, and we need to fix that?
>>
>> If the ieee80211_num_beaconing_links() is modified then deflink check is
>> not required. Do you want to me to send a clean up for that function
>> first or would take this and later the clean up part?
> 
> Given that you're targeting wireless-next for all, I guess I'd prefer
> you clean up ieee80211_num_beaconing_links() first? But no strong
> preferences.

Okay sure let me first send a clean up. So, 
ieee80211_num_beaconing_links() should return 1 for non-MLO as well? And 
callers should test for == 1 instead of <= 1.

> 
>>> Also seems the VLAN carrier handling is broken.
>> With this patch? Or in general you are saying? HWSIM test cases seems to
>> be working fine for me with this series applied. May be there is no test
>> case to make it evident?
> 
> Oh, I meant in general.
> 
> So here I looked at callers of ieee80211_num_beaconing_links(), and many
> of them seemed wrong because it doesn't handle non-MLO? But now that I
> look again, I'm actually wrong, it simply always returns 0 for non-MLO,
> but the comparisons are for <=1 which makes that ... OK but unexpected I
> guess.
> 
> 
> But still - also unrelated to this patch - the VLAN handling here seems
> wrong?
> 
Yes VLAN handling with MLO is not handled with the change which brought 
this beaconing links API.

>          if (ieee80211_num_beaconing_links(sdata) <= 1)
>                  netif_carrier_on(dev);
> 
>          list_for_each_entry(vlan, &sdata->u.ap.vlans, u.vlan.list)
>                  netif_carrier_on(vlan->dev);
> 
> Shouldn't that loop be inside the ieee80211_num_beaconing_links() if?
> Also on the netif_carrier_off() side? At least someone was fixing VLAN
> vs. MLO recently, so maybe that needs fixes too.
> 

Yes. MLO VLAN changes should handle this part. Since at this moment, 
code does not claim to support MLO VLAN fully. So change introducing the 
support should ideally handle it.

-- 
Aditya

Re: [PATCH wireless-next 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO

[Johannes Berg]

On Tue, 2025-05-13 at 16:02 +0530, Aditya Kumar Singh wrote:
> 
> Okay sure let me first send a clean up. So, 
> ieee80211_num_beaconing_links() should return 1 for non-MLO as well?
> 

That would seem logical to me? For this and many other things non-MLO is
mostly equivalent to just having a single link (apart from the address
translation.)

> And callers should test for == 1 instead of <= 1.

Not even sure that matters enough to need to change?

johannes

Re: [PATCH wireless-next 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO

[Aditya Kumar Singh]

On 5/13/2025 4:18 PM, Johannes Berg wrote:
> On Tue, 2025-05-13 at 16:02 +0530, Aditya Kumar Singh wrote:
>>
>> Okay sure let me first send a clean up. So,
>> ieee80211_num_beaconing_links() should return 1 for non-MLO as well?
>>
> 
> That would seem logical to me? For this and many other things non-MLO is
> mostly equivalent to just having a single link (apart from the address
> translation.)

Yeah in a way true only.

> 
>> And callers should test for == 1 instead of <= 1.
> 
> Not even sure that matters enough to need to change?
yeah can be left as it is. Sure then I will change the function alone to 
return 1 for non-MLO case as well.

Thanks for the inputs :)

-- 
Aditya

Re: [PATCH wireless-next 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO

[Aditya Kumar Singh]

On 5/13/2025 4:26 PM, Aditya Kumar Singh wrote:
> On 5/13/2025 4:18 PM, Johannes Berg wrote:
>> On Tue, 2025-05-13 at 16:02 +0530, Aditya Kumar Singh wrote:
>>>
>>> Okay sure let me first send a clean up. So,
>>> ieee80211_num_beaconing_links() should return 1 for non-MLO as well?
>>>
>>
>> That would seem logical to me? For this and many other things non-MLO is
>> mostly equivalent to just having a single link (apart from the address
>> translation.)
> 
> Yeah in a way true only.
> 
>>
>>> And callers should test for == 1 instead of <= 1.
>>
>> Not even sure that matters enough to need to change?
> yeah can be left as it is. Sure then I will change the function alone to 
> return 1 for non-MLO case as well.
> 
> Thanks for the inputs :)
> 

Done. Here is the clean up patch for review -
Link: 
https://lore.kernel.org/all/20250515-fix_num_beaconing_links-v1-1-4a39e2704314@oss.qualcomm.com/

-- 
Aditya

[PATCH wireless-next 2/2] wifi: mac80211: accept probe response on link address as well

[Aditya Kumar Singh]

If a random MAC address is not requested during scan request, unicast probe
response frames are only accepted if the destination address matches the
interface address. This works fine for non-ML interfaces. However, with
MLO, the same interface can have multiple links, and a scan on a link would
be requested with the link address. In such cases, the probe response frame
gets dropped which is incorrect.

Therefore, add logic to check if any of the link addresses match the
destination address if the interface address does not match.

Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
---
 net/mac80211/scan.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index cb707907188585d6874bf290874bdb0ca33bb399..7b8da40a912d020f229a74c67bd5a57fb513a72d 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -240,6 +240,9 @@ static bool ieee80211_scan_accept_presp(struct ieee80211_sub_if_data *sdata,
 					struct ieee80211_channel *channel,
 					u32 scan_flags, const u8 *da)
 {
+	struct ieee80211_link_data *link_sdata;
+	u8 link_id;
+
 	if (!sdata)
 		return false;
 
@@ -251,7 +254,20 @@ static bool ieee80211_scan_accept_presp(struct ieee80211_sub_if_data *sdata,
 
 	if (scan_flags & NL80211_SCAN_FLAG_RANDOM_ADDR)
 		return true;
-	return ether_addr_equal(da, sdata->vif.addr);
+
+	if (ether_addr_equal(da, sdata->vif.addr))
+		return true;
+
+	for (link_id = 0; link_id < IEEE80211_MLD_MAX_NUM_LINKS; link_id++) {
+		link_sdata = rcu_dereference(sdata->link[link_id]);
+		if (!link_sdata)
+			continue;
+
+		if (ether_addr_equal(da, link_sdata->conf->addr))
+			return true;
+	}
+
+	return false;
 }
 
 void ieee80211_scan_rx(struct ieee80211_local *local, struct sk_buff *skb)

-- 
2.34.1