[PATCH 1/1] MBO: Check association disallowed attribute in beacons and probe responses

[Jouni Malinen]

On Fri, Jan 28, 2022 at 05:25:46PM +0800, Kuan-Chung Chen wrote:
> When a station receives a beacon, probe response from an AP that
> contains an MBO IE with the association disallowed attribute,
> the station should prevent association to that AP.

That is what the current implementation is doing.. Could you please
clarify why these additional changes would be needed?

> @@ -1408,7 +1408,7 @@ static bool wpa_scan_res_ok(struct wpa_supplicant *wpa_s, struct wpa_ssid *ssid,
> -	assoc_disallow = wpas_mbo_get_bss_attr(bss, MBO_ATTR_ID_ASSOC_DISALLOW);
> +	assoc_disallow = wpas_mbo_check_assoc_disallow(bss);

> +const u8 * wpas_mbo_check_assoc_disallow(struct wpa_bss *bss)
> +{
> +	const u8 *assoc_disallow;
> +
> +	assoc_disallow = wpas_mbo_get_bss_attr(bss, MBO_ATTR_ID_ASSOC_DISALLOW);
> +	if (assoc_disallow && assoc_disallow[1] >= 1)
> +		return assoc_disallow;

So this part would maintain the current functionality, i.e., check the
MBO attribute from the current scan results for the AP based on Probe
Response frame, if available, or Beacon frame.

> +	assoc_disallow = wpas_mbo_get_bss_attr_beacon(bss, MBO_ATTR_ID_ASSOC_DISALLOW);
> +	if (assoc_disallow && assoc_disallow[1] >= 1)
> +		return assoc_disallow;

While this would be the extra step that would fall back to using the
Beacon frame if there was a Probe Response frame that did not include
the association disallowed attribute. Why would this be needed? Why
would an AP provide conflicting information about the state between
Probe Response and Beacon frames?

-- 
Jouni Malinen                                            PGP id EFC895FA