mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH wireless-next v2 0/2] wifi: mac80211: some bug fixes in MLO scan handling
@ 2025-05-16 10:32 Aditya Kumar Singh
  2025-05-16 10:32 ` [PATCH wireless-next v2 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO Aditya Kumar Singh
  2025-05-16 10:32 ` [PATCH wireless-next v2 2/2] wifi: mac80211: accept probe response on link address as well Aditya Kumar Singh
  0 siblings, 2 replies; 3+ messages in thread
From: Aditya Kumar Singh @ 2025-05-16 10:32 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, linux-kernel, 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.

---
Changes in v2:
- Use ieee80211_num_beaconing_links() alone since now it can handle non-mlo
  as well.
- Link to v1: https://lore.kernel.org/r/20250513-bug_fix_mlo_scan-v1-0-94235bb42fbe@oss.qualcomm.com

---
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  |  2 +-
 net/mac80211/scan.c | 18 +++++++++++++++++-
 2 files changed, 18 insertions(+), 2 deletions(-)
---
base-commit: 68b44b05f4c880c42109a91d2e0e7faa94f40529
change-id: 20250402-bug_fix_mlo_scan-fe57f57b1c86


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH wireless-next v2 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO
  2025-05-16 10:32 [PATCH wireless-next v2 0/2] wifi: mac80211: some bug fixes in MLO scan handling Aditya Kumar Singh
@ 2025-05-16 10:32 ` Aditya Kumar Singh
  2025-05-16 10:32 ` [PATCH wireless-next v2 2/2] wifi: mac80211: accept probe response on link address as well Aditya Kumar Singh
  1 sibling, 0 replies; 3+ messages in thread
From: Aditya Kumar Singh @ 2025-05-16 10:32 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, linux-kernel, 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 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 05b7296b152cfbe1e81f8981eee52d72f711706c..d9d88f2f283120ba366401d3ac546e59d8c61c21 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2924,7 +2924,7 @@ 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 (ieee80211_num_beaconing_links(sdata) &&
 		    (!(wiphy->features & NL80211_FEATURE_AP_SCAN) ||
 		     !(req->flags & NL80211_SCAN_FLAG_AP)))
 			return -EOPNOTSUPP;

-- 
2.34.1


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [PATCH wireless-next v2 2/2] wifi: mac80211: accept probe response on link address as well
  2025-05-16 10:32 [PATCH wireless-next v2 0/2] wifi: mac80211: some bug fixes in MLO scan handling Aditya Kumar Singh
  2025-05-16 10:32 ` [PATCH wireless-next v2 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO Aditya Kumar Singh
@ 2025-05-16 10:32 ` Aditya Kumar Singh
  1 sibling, 0 replies; 3+ messages in thread
From: Aditya Kumar Singh @ 2025-05-16 10:32 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, linux-kernel, 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-05-16 10:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-05-16 10:32 [PATCH wireless-next v2 0/2] wifi: mac80211: some bug fixes in MLO scan handling Aditya Kumar Singh
2025-05-16 10:32 ` [PATCH wireless-next v2 1/2] wifi: mac80211: validate SCAN_FLAG_AP in scan request during MLO Aditya Kumar Singh
2025-05-16 10:32 ` [PATCH wireless-next v2 2/2] wifi: mac80211: accept probe response on link address as well Aditya Kumar Singh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®