[PATCH] wifi: mac80211: determine missing link_id in ieee80211_rx_for_interface() based on band

[PATCH] wifi: mac80211: determine missing link_id in ieee80211_rx_for_interface() based on band

[Michael-CY Lee]

For broadcast frames, every interface might have to process it and
therefore the link_id cannot be determined in the driver.

When the frame is about to be forwarded to each interface, we can
use the member "band" in struct ieee80211_rx_status to determine the
"link_id" for each interface.

Signed-off-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Reviewed-by: Money Wang <money.wang@mediatek.com>
---
 net/mac80211/rx.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 09beb65d6108..7671fd39a60e 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -5115,8 +5115,28 @@ static bool ieee80211_rx_for_interface(struct ieee80211_rx_data *rx,
 		struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
 
 		sta = sta_info_get_bss(rx->sdata, hdr->addr2);
-		if (status->link_valid)
+		if (status->link_valid) {
 			link_id = status->link_id;
+		} else if (ieee80211_vif_is_mld(&rx->sdata->vif)) {
+			struct ieee80211_supported_band *sband;
+			struct ieee80211_link_data *link;
+			int i;
+
+			for_each_valid_link(&rx->sdata->wdev, i) {
+				link = rcu_dereference(rx->sdata->link[i]);
+				if (!link)
+					continue;
+
+				sband = ieee80211_get_link_sband(link);
+				if (!sband)
+					continue;
+
+				if (status->band == sband->band) {
+					link_id = i;
+					break;
+				}
+			}
+		}
 	}
 
 	if (!ieee80211_rx_data_set_sta(rx, sta, link_id))
-- 
2.25.1

Re: [PATCH] wifi: mac80211: determine missing link_id in ieee80211_rx_for_interface() based on band

[Johannes Berg]

On Wed, 2025-07-02 at 18:44 +0800, Michael-CY Lee wrote:
> For broadcast frames, every interface might have to process it and
> therefore the link_id cannot be determined in the driver.
> 
> When the frame is about to be forwarded to each interface, we can
> use the member "band" in struct ieee80211_rx_status to determine the
> "link_id" for each interface.

Hm. Qualcomm has a similar thing with frequency, I think, and that
probably makes more sense for them since 'band' isn't unique for the
radio:

https://lore.kernel.org/linux-wireless/20250612121127.1960948-3-maharaja.kennadyrajan@oss.qualcomm.com/

Or is it not related?

johannes

Re: [PATCH] wifi: mac80211: determine missing link_id in ieee80211_rx_for_interface() based on band

[Michael-CY Lee]

On Wed, 2025-07-02 at 12:52 +0200, Johannes Berg wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> On Wed, 2025-07-02 at 18:44 +0800, Michael-CY Lee wrote:
> > For broadcast frames, every interface might have to process it and
> > therefore the link_id cannot be determined in the driver.
> > 
> > When the frame is about to be forwarded to each interface, we can
> > use the member "band" in struct ieee80211_rx_status to determine
> > the
> > "link_id" for each interface.
> 
> Hm. Qualcomm has a similar thing with frequency, I think, and that
> probably makes more sense for them since 'band' isn't unique for the
> radio:
> 
> https://lore.kernel.org/linux-wireless/20250612121127.1960948-3-maharaja.kennadyrajan@oss.qualcomm.com/
> 
> Or is it not related?
> 
> johannes

Hi Johannes,

I think they're related but address different issues about group-
addressed frames.

The Qualcomm patch seems to focus on preventing frames from getting
processed on an interface running on a different band. (referred from
their commit message)
For example, a frame from frequency 6135 MHz should not be processed by
an interface that does not have a link on frequency 6135 MHz.

On the other hand, the problem we encountered is that the interface is
going to process the frame, but the "status->link_valid" is unset
because the driver is incapable of determining the "link_id". The
"link_id" remains its default value of -1, and the frame is handled by
the interface's default link and is dropped because an AP MLD interface
is not using its default link (sdata->deflink).

In summary, the Qualcomm patch focuses on avoiding frames being
processed by unsuitable interfaces, while our patch aims to determine
the "link_id" so that the interface can correctly handle it.

Additionally, we also think the 'link_id' can be determined based on
'freq' rather than 'band'. What do you think?

Best,
Michael

Re: [PATCH] wifi: mac80211: determine missing link_id in ieee80211_rx_for_interface() based on band

[Johannes Berg]

Hi,

[btw, you're sending HTML that looks like plain text, seems redundant
and also made the links non-clickable here? maybe try to change that]

> > Hm. Qualcomm has a similar thing with frequency, I think, and that
> > probably makes more sense for them since 'band' isn't unique for the
> > radio:
> > 
> > https://lore.kernel.org/linux-wireless/20250612121127.1960948-3-maharaja.kennadyrajan@oss.qualcomm.com/
> > 
> > Or is it not related?

> I think they're related but address different issues about group-
> addressed frames.

OK, fair.

> The Qualcomm patch seems to focus on preventing frames from getting
> processed on an interface running on a different band. (referred from
> their commit message)
> For example, a frame from frequency 6135 MHz should not be processed by
> an interface that does not have a link on frequency 6135 MHz.

Right, it's just in some way I thought many frames should be processed
for a link in the first place, though I guess you're thinking more
generally, and the other patch was explicitly about data frames for
which that of course isn't really true.

> On the other hand, the problem we encountered is that the interface is
> going to process the frame, but the "status->link_valid" is unset
> because the driver is incapable of determining the "link_id". The
> "link_id" remains its default value of -1, and the frame is handled by
> the interface's default link and is dropped because an AP MLD interface
> is not using its default link (sdata->deflink).

Right.

> In summary, the Qualcomm patch focuses on avoiding frames being
> processed by unsuitable interfaces, while our patch aims to determine
> the "link_id" so that the interface can correctly handle it.

OK.

> Additionally, we also think the 'link_id' can be determined based on
> 'freq' rather than 'band'. What do you think?

I'm starting to wonder if either should be in mac80211 at all, but I
guess if you both need it why not :)

I'd say we should be consistent, and use the frequency because there are
(likely? going to be?) devices with two separate low/high 5 GHz links.

johannes