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
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
