hostapd: avoid unnecessary beacon update for co-location

[Jouni Malinen]

On Fri, Oct 13, 2023 at 01:43:57PM +0800, Michael-CY Lee wrote:
> When it comes to set some BSS's beacon, there are two reasons to update
> the beacon of co-located hostapd_iface(s) at the same time:
> 1. 6 GHz out-of-band discovery
> 2. MLD operational parameters update
> 
> BSS load update is unrelated with the above two reasons, and
> therefore is not the case to update beacon for co-location.
> Moreover, updating beacon for co-location when BSS load update makes
> hostapd set beacon too frequently, which makes hostapd busy setting
> beacon in a multi-BSS case.

I can understand the BSS load update part..

> Besides, it is also not necessary to update beacon for co-location when
> current BSS is neigher 6 GHz nor MLD.

But does this cover all cases?

> @@ -2246,7 +2252,7 @@ int ieee802_11_set_beacon(struct hostapd_data *hapd)
> -		if (is_6g == is_6ghz_op_class(other->conf->op_class) &&
> +		if ((!is_6g || is_6ghz_op_class(other->conf->op_class)) &&
>  		    !mld_ap)
>  			continue;

This functionality was added in commit
f17f7ca4e07c5aaf96d4d7c08085c5f36eed9d61 to update the 2.4/5 GHz Beacon
frames whenever there is a change in the 6 GHz Beacon frame. However, it
does have this additional function:
						       Similarly, RNR is
    included in FILS Discovery frames by default in 6 GHz-only mode,
    updating the Beacon frames will remove it when co-located 2.4/5 GHz
    interfaces are brought up.

Would that be covered by the proposed change?

-- 
Jouni Malinen                                            PGP id EFC895FA