Discussion on commit "MLD: Scan the channels of missing links for the ML probe"

[Louis Kotze]

Hi Michael,

Thanks for the review, and for the detail. I agree with both points and
have sent a revert of that commit to the list:
https://www.google.com/url?q=https://lists.infradead.org/pipermail/hostap/2026-August/045453.html&source=gmail&ust=1786785912152000&sa=E
Adding hostap@ to Cc, since this concerns a commit that is already in
the tree.

> If multiple channels/frequencies are specified during the scan for the
> ML probe, the params.bssid will not be set in the function
> wpa_supplicant_scan() even if wpa_s->ml_probe_bssid is set, causing the
> ML probe request to be sent as a broadcast frame.

Confirmed, and it is worse than only the frame that goes out on the
other channels. With more than one entry in the frequency list, no
BSSID is passed to the driver at all, so cfg80211 falls back to the
wildcard BSSID and mac80211 sets both Address 1 and Address 3 of every
Probe Request frame in the scan to the broadcast address, including the
one sent on the association link's channel. That was a deliberate
trade-off in the commit rather than an oversight, but the trade-off was
the wrong one.

I checked this against 35.3.4.2 in IEEE Std 802.11be-2024, which
requires a multi-link probe request to be sent "[e]ither with the
Address 1 field set to the broadcast address and the Address 3 field set
to the BSSID of an AP, or with the Address 1 and Address 3 fields set to
the BSSID of an AP". A broadcast Address 3 is neither of those, so your
reading is right.

> When scanning for the ML probe request, wpa_supplicant passes the
> Multi-Link Element (MLE) to the kernel via params.extra_ies. This MLE
> is inherently bound to a specific band.

Agreed, and the same clause makes the consequence concrete. The
requested APs are the APs affiliated with the same AP MLD as the AP
identified in the Address 1 or Address 3 field or in the AP MLD ID
subfield. With both address fields set to the broadcast address, no AP
is identified by address, so an AP MLD that is not the intended target
resolves the requested link IDs against itself and responds with per-STA
profiles of its own affiliated APs. The element being bound to the
association link and the Address 3 problem are really the same defect
seen from two sides.

> If there is a strong requirement to scan for missing links multiple
> channels, perhaps we could achieve this by splitting the process into
> multiple separate scan requests instead of doing it all at once?

I think that is the right approach, and I would like to follow up with
it. One detail is worth recording, because it rules out the smaller fix
that the first point suggests.

Keeping the extra channels in the scan and simply restoring
params.bssid does not work for a missing link on 6 GHz.
wpa_supplicant sets NL80211_SCAN_FLAG_COLOCATED_6GHZ by default, and
cfg80211_scan_6ghz() only adds a colocated 6 GHz AP's channel when the
scan request's BSSID is the wildcard or matches that AP's own BSSID.
With the association link's BSSID in the request, the 6 GHz affiliated
AP is filtered out and its channel is not scanned. Since only one BSSID
can be specified per scan request, the correct Address 3 for each link
is not expressible within a single scan, which is what makes separate
scan requests necessary rather than merely tidier.

What I have in mind for the follow-up:

- The ML probe request itself stays exactly as it is today: the
association link's channel, Address 3 set to that AP's BSSID, and the
Multi-Link element listing the missing links.

- Only if links are still missing after that, one further scan request
per remaining link, on that link's channel and with Address 3 set to
the affiliated AP's own BSSID. Both are already known from the RNR
information in the association link's scan entry. No Multi-Link
element is needed on those, since the AP's own Probe Response frame
carries what is missing.

There is also a testability gap that I should have noticed earlier. The
case this was addressing is an AP MLD that does not return complete
per-STA profiles for the requested links, and hostapd always returns
them, so it cannot be reproduced in the hwsim tests. Would a
CONFIG_TESTING_OPTIONS parameter on the AP side to omit requested
per-STA profiles from the ML probe response be acceptable? That would
give the follow-up test coverage rather than leaving it resting on a
single AP observation.

One request on the revert: it applies to that commit only. The other two
commits in the series should stay. Without them an affiliated link whose
scan entry is older than the kernel accepts is still included in the
association request, and the association fails in the kernel with "Error
fetching BSS for link" instead of proceeding on the remaining links.

If MediaTek would be able to test the follow-up on an AP MLD, that would
be very welcome.

Thanks,
Louis


On Fri, Aug 14, 2026 at 3:56 AM Michael-cy Lee (李峻宇)
<Michael-cy.Lee at mediatek.com> wrote:
>
> Hi Louis Kotze,
>
>
>
> We are writing to share some feedback regarding your recent commit:
>
> "MLD: Scan the channels of missing links for the ML probe". (commit ID: 517b0d7cc8412afa202a0f97b68c32b4ac5b44af)
>
>
>
> We have found that this change might introduce a standard violation and a potential issue.
>
> Here are the two main concerns:
>
> 1. Standard Violation (Broadcast ML Probe Request):
>
> If multiple channels/frequencies are specified during the scan for the ML probe, the params.bssid will not be set in the function wpa_supplicant_scan() even if wpa_s->ml_probe_bssid is set, causing the ML probe request to be sent as a broadcast frame.
>
> This violates the IEEE 802.11be standard. According to section 35.3.4.2 (Use of multi-link probe request and response), the Address 3 (A3) field of an ML probe request must be the AP's BSSID.
>
>
>
> Unexpected Behavior due to Band-bound MLE:
>
> When scanning for the ML probe request, wpa_supplicant passes the Multi-Link Element (MLE) to the kernel via params.extra_ies. This MLE is inherently bound to a specific band. For example, if the intention is to send the ML probe request from link 0, the MLE might have link 1 and link 2 specified in the per-STA profile. If this particular MLE ends up being transmitted on link 1 or link 2 instead (due to scanning multiple channels), it may lead to unexpected behaviors.
>
>
>
> Based on the points above, we recommend reverting this commit for now..
>
>
>
> If there is a strong requirement to scan for missing links multiple channels, perhaps we could achieve this by splitting the process into multiple separate scan requests instead of doing it all at once? Let me know what you think about this approach.
>
>
>
> Thanks,
>
> Michael
>
> *********** MEDIATEK Confidentiality Notice
>  ***********
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or
> otherwise exempt from disclosure under applicable laws. It is
> intended to be conveyed only to the designated recipient(s). Any
> use, dissemination, distribution, printing, retaining or copying
> of this e-mail (including its attachments) by unintended recipient(s)
> is strictly prohibited and may be unlawful. If you are not an
> intended recipient of this e-mail, or believe that you have received
> this e-mail in error, please notify the sender immediately
> (by replying to this e-mail), delete any and all copies of this
> e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!