[PATCH wireless-next v3 0/2] wifi: mac80211: Fix Rx packet handling in multi-radio devices

[PATCH wireless-next v3 0/2] wifi: mac80211: Fix Rx packet handling in multi-radio devices

[Maharaja Kennadyrajan]

This patch series addresses issues related to the handling of Rx group
addressed data and management frames in multi-radio devices with ath12k
driver. These frames don't have the destination station information, unlike
unicast Rx frames, and are forwarded to all the active sdata of the device.

This happens because currently there is no check to ensure if the sdata is
running on the same band as the frames are received on before start
processing those frames.

The patches ensure that packets are correctly processed and forwarded only
to the appropriate interfaces by mandating the ieee80211_rx_status::freq
for group addressed data frames and check the operating frequency against
the rx_status->freq and forward to the appropriate interface when the
frequency matches.

v3: Changed from RFC to PATCH.

v2: Addressed Johannes's comments.
    * Changed to for_each_link_data() from for_each_set_bit()
    * Removed boolean variable and return with bool value.
    * Combined the if condition.

Maharaja Kennadyrajan (2):
  wifi: mac80211: update ieee80211_rx_status::freq documentation for
    multi-radio
  wifi: mac80211: process group addressed Rx data and mgmt packets on
    intended interface

 include/net/mac80211.h |  6 ++++--
 net/mac80211/rx.c      | 48 +++++++++++++++++++++++++++++++++++-------
 2 files changed, 44 insertions(+), 10 deletions(-)


base-commit: 0b0ff976af94fc2437b62e3798f11aacc3798613
-- 
2.17.1

[PATCH wireless-next v3 1/2] wifi: mac80211: update ieee80211_rx_status::freq documentation for multi-radio

[Maharaja Kennadyrajan]

With multi-radio device, it has been observed that the group-addressed
management/data Rx frames, which are actually received on one band, are
getting processed on an interface running on a different band.

This occurs because there is currently no check to ensure that the sdata is
running on the same band as the frames are received on before start
processing those frames.

Update the documentation of ieee80211_rx_status::freq to make it
mandatory for group-addressed data frames in multi-radio device.

Drivers such as ath12k and mediatek(mt76) are currently supporting
multi-radio and report ieee80211_rx_status::freq in their Rx frame
indication to the mac80211 driver.

Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
---
 include/net/mac80211.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 82617579d910..9212c2089638 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1612,8 +1612,10 @@ enum mac80211_rx_encoding {
  *	it but can store it and pass it back to the driver for synchronisation
  * @band: the active band when this frame was received
  * @freq: frequency the radio was tuned to when receiving this frame, in MHz
- *	This field must be set for management frames, but isn't strictly needed
- *	for data (other) frames - for those it only affects radiotap reporting.
+ *	This field must be set for management frames, also for group
+ *	addressed data frames in case of multi-radio device, but otherwise
+ *	this isn't strictly needed for data (other) frames - for those it
+ *	only affects radiotap reporting.
  * @freq_offset: @freq has a positive offset of 500Khz.
  * @signal: signal strength when receiving this frame, either in dBm, in dB or
  *	unspecified depending on the hardware capabilities flags
-- 
2.17.1

[PATCH wireless-next v3 2/2] wifi: mac80211: process group addressed Rx data and mgmt packets on intended interface

[Maharaja Kennadyrajan]

Currently, in multi-radio devices, group-addressed data and management
frames received on one band are getting processed on an interface running
on a different band. This occurs because these frames do not have the
destination station information, unlike unicast Rx frame processing where
the transmitting station is known.

There is no check to ensure that the sdata is running on the same band as
the frames are received on before processing those frames.

Fix this by checking the operating frequency of the interface against the
frequency of the packets received before forwarding them to the interface
in multi-radio devices.

The current behavior is retained as a fallback mechanism when the frequency
is not reported by the drivers.

Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com>
---
 net/mac80211/rx.c | 48 +++++++++++++++++++++++++++++++++++++++--------
 1 file changed, 40 insertions(+), 8 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 09beb65d6108..59028c08dd52 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -5125,6 +5125,30 @@ static bool ieee80211_rx_for_interface(struct ieee80211_rx_data *rx,
 	return ieee80211_prepare_and_rx_handle(rx, skb, consume);
 }
 
+static bool
+ieee80211_rx_is_sdata_match(struct ieee80211_sub_if_data *sdata,
+			    int freq)
+{
+	struct ieee80211_link_data *link;
+	struct ieee80211_bss_conf *bss_conf;
+	struct ieee80211_chanctx_conf *conf;
+
+	if (!freq)
+		return true;
+
+	for_each_link_data(sdata, link) {
+		bss_conf = link->conf;
+		if (!bss_conf)
+			continue;
+		conf = rcu_dereference(bss_conf->chanctx_conf);
+		if (conf && conf->def.chan &&
+		    conf->def.chan->center_freq == freq)
+			return true;
+	}
+
+	return false;
+}
+
 /*
  * This is the actual Rx frames handler. as it belongs to Rx path it must
  * be called with rcu_read_lock protection.
@@ -5264,18 +5288,26 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
 		 * the loop to avoid copying the SKB once too much
 		 */
 
-		if (!prev) {
-			prev = sdata;
-			continue;
-		}
+		/* Process the group addressed management and data packets
+		 * in the intended interface when the operating frequency
+		 * matches with rx_status->freq in multi-radio devices.
+		 * If rx_status->freq is not set by the driver, then
+		 * follow the existing code flow.
+		 */
 
-		rx.sdata = prev;
-		ieee80211_rx_for_interface(&rx, skb, false);
+		if (ieee80211_rx_is_sdata_match(sdata, status->freq)) {
+			if (!prev) {
+				prev = sdata;
+				continue;
+			}
 
-		prev = sdata;
+			rx.sdata = prev;
+			ieee80211_rx_for_interface(&rx, skb, false);
+			prev = sdata;
+		}
 	}
 
-	if (prev) {
+	if (prev && ieee80211_rx_is_sdata_match(prev, status->freq)) {
 		rx.sdata = prev;
 
 		if (ieee80211_rx_for_interface(&rx, skb, true))
-- 
2.17.1

Re: [PATCH wireless-next v3 2/2] wifi: mac80211: process group addressed Rx data and mgmt packets on intended interface

[kernel test robot]

Hello,

kernel test robot noticed "hwsim.pasn_kdk_derivation.fail" on:

commit: 9b295898d736daa9f3287430f4bef5481ee0e99c ("[PATCH wireless-next v3 2/2] wifi: mac80211: process group addressed Rx data and mgmt packets on intended interface")
url: https://github.com/intel-lab-lkp/linux/commits/Maharaja-Kennadyrajan/wifi-mac80211-update-ieee80211_rx_status-freq-documentation-for-multi-radio/20250523-195936
patch link: https://lore.kernel.org/all/20250523115838.481402-3-maharaja.kennadyrajan@oss.qualcomm.com/
patch subject: [PATCH wireless-next v3 2/2] wifi: mac80211: process group addressed Rx data and mgmt packets on intended interface

in testcase: hwsim
version: hwsim-x86_64-4b8ac10cb-1_20250525
with following parameters:

	test: pasn_kdk_derivation



config: x86_64-rhel-9.4-func
compiler: gcc-12
test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4790 v3 @ 3.60GHz (Haswell) with 6G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)




If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202506032129.39ad1ab-lkp@intel.com

group: group-34, test: pasn_kdk_derivation
2025-05-30 22:20:38 export USER=root
2025-05-30 22:20:38 ./build.sh
Building TNC testing tools
Building wlantest
Building hs20-osu-client
Building hostapd
Building wpa_supplicant
2025-05-30 22:21:27 ./start.sh
2025-05-30 22:21:28 ./run-tests.py pasn_kdk_derivation
DEV: wlan0: 02:00:00:00:00:00
DEV: wlan1: 02:00:00:00:01:00
DEV: wlan2: 02:00:00:00:02:00
APDEV: wlan3
APDEV: wlan4
START pasn_kdk_derivation 1/1
Test: PASN authentication with forced KDK derivation
Starting AP wlan3
Starting AP wlan4
PASN: unexpected status
Traceback (most recent call last):
  File "/lkp/benchmarks/hwsim/tests/hwsim/./run-tests.py", line 591, in main
    t(dev, apdev)
  File "/lkp/benchmarks/hwsim/tests/hwsim/test_pasn.py", line 925, in test_pasn_kdk_derivation
    check_pasn_akmp_cipher(dev[0], hapd0, "PASN", "CCMP")
  File "/lkp/benchmarks/hwsim/tests/hwsim/test_pasn.py", line 122, in check_pasn_akmp_cipher
    raise Exception("PASN: unexpected status")
Exception: PASN: unexpected status
FAIL pasn_kdk_derivation 3.876573 2025-05-30 22:21:33.773779
passed 0 test case(s)
skipped 0 test case(s)
failed tests: pasn_kdk_derivation
2025-05-30 22:21:33 ./stop.sh



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250603/202506032129.39ad1ab-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki