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@xxxxxxxxxxxxxxxx/ > > 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
