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

[Damon Chen]

Dear Jouni Malinen,

In my test scenario, the test steps can be simplified as follows:
1. Configure the AP without association disallowed
2. Trigger STA connect to the AP
3. STA disconnect from the AP
4. Configure the AP with association disallowed
5. Trigger STA connect to the AP

In step 5, STA should not send association request.
But if the operating channel is NO_IR, STA will not send probe request in step 5 due to the passive scan, then wpa_supplicant will get the old probe response from step 2.

The probe response from step 2 does not include the association disallow attribute, therefore, wpa_supplicant will start the association process although the beacon has included the association disallow attribute from step 5.

Thanks.

-----Original Message-----
From: Jouni Malinen <j at w1.fi> 
Sent: Friday, March 4, 2022 6:20 PM
To: Damon Chen <damon.chen at realtek.com>
Cc: hostap at lists.infradead.org
Subject: Re: [PATCH 1/1] MBO: Check association disallowed attribute in beacons and probe responses

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