[PATCH V3 7/7] rnr: add reduced neighbor reporting

[Jouni Malinen]

On Mon, Sep 21, 2020 at 01:51:02PM +0200, John Crispin wrote:
> The Reduced Neighbor Report (rnr) element contains channel and other
> information related to neighbor APs. It is part of the OCE requirement.

> diff --git a/hostapd/hostapd.conf b/hostapd/hostapd.conf
> @@ -2775,6 +2775,9 @@ own_ip_addr=127.0.0.1
> +# Enable reduced neighbour reporting (RNR)
> +#rnr_beacon=0

It would be helpful to provide some more detail on when this should be
enabled and whether it is enabled on all the radios of a co-located AP
with 2.4/5/6 GHz radios. Similarly to the other hostapd.conf change, it
would be good to explicitly document to possible values and their
meaning.

Is rnr_beacon appropriate name for this parameter? The change in
hostapd_gen_probe_resp() seems to imply that this would not be limited
to Beacon frames.

> diff --git a/src/ap/ap_config.h b/src/ap/ap_config.h
> +	u8 rnr_beacon;

If this is a boolean parameter, it would likely make more sense to use
bool instead of u8 now that hostap.git has started using bool in new
changes.

> diff --git a/src/ap/ieee802_11.c b/src/ap/ieee802_11.c
> @@ -5745,4 +5745,140 @@ u8 * hostapd_eid_multiple_bssid(struct hostapd_data *hapd, u8 *eid, u8 *end,
> +size_t hostapd_eid_reduced_neighbor_report_len(struct hostapd_data *hapd, bool probe_resp)
> +{
> +	size_t len = 0;
> +	int i;
> +
> +	if (hapd->iface->num_bss > 1)
> +		len += TBTT_HEADER_LENGTH + ((hapd->iface->num_bss - 1) * TBTT_INFO_LENGTH);
> +	for (i = 0; i < hapd->iface->interfaces->count; i++) {
> +		struct hostapd_iface *iface = hapd->iface->interfaces->iface[i];
> +
> +		if (iface == hapd->iface || !iface->conf->he_co_locate)
> +			continue;
> +
> +		len += TBTT_HEADER_LENGTH + (iface->num_bss * TBTT_INFO_LENGTH);
> +	}
> +
> +	if (!probe_resp && !dl_list_empty(&hapd->nr_db))
> +		len += dl_list_len(&hapd->nr_db) * (TBTT_HEADER_LENGTH + TBTT_INFO_LENGTH);
> +
> +	return len;

Is there any risk of len being too large to fit into an information
element? If so, this design would not seem to work without support for
dropping out some extra entries or supporting fragmentation of the IEs.


PS.

I dropped the full patchset from my queue now since the couple of
patches for which I did not have a comment do not make much sense on
their own without this last patch and/or would depend on the other
patches for which there are open comments.

-- 
Jouni Malinen                                            PGP id EFC895FA