[PATCH] WNM: Fallback to full scan when BTM contains incorrect channel info

[Benjamin Berg]

On Fri, 2025-10-10 at 11:43 -0700, Ashish Shukla wrote:
> On Fri, Oct 10, 2025 at 7:55 AM Benjamin Berg <benjamin at sipsolutions.net> wrote:
> > 
> > Hi,
> > 
> > it would be good if you put the patch into the mail directly rather
> > than attaching it. Other than that, you should also adjust the
> > indentation for the nei->freq parameter.
> > 
> Ack.
> 
> 
> > 
> > Do you have an example of an RNR with incorrect information (and maybe
> > information of where the AP is actually)?
> > 
> This is from a customer device logs using Wi-Fi 7 AP, which I don't
> have access to.

Really, all we need is information about the RNR from the BTM request.
Even a local packet capture from the client or the wpa_supplicant debug
log should be sufficient for this.

> > From a logic perspective, this does not seem quite right to me. We do
> > not want to trigger a full scan, just because we are unable to e.g. use
> > the 6 GHz band in our station.
> > 
> The proposed patch does not regress behavior with good APs. Only for the
> APs that have incorrect channels it performs full scans. For these APs missing
> higher bands bssids results device falling back to 2.4Ghz.

If for example, you have a client that does not support 6 GHz, and the
AP announces in the RNR that there is a 6 GHz AP available, then this
entry will trigger a full scan with your code. This is incorrect, the
corresponding RNR entry needs to be ignored by the client as it knows
that it is unable to connect.

> > Though I do see now that there is a small bug and we should move the
> > 
> >   has_6ghz |= is_6ghz_freq(nei->freq);
> > 
> > assignment into the same chan_supported check. I'll submit a patch for
> > that.
> > 
> If you agree with above, the the current patch would address this as well.

It would, but I disagree.

> > Depending on what the AP reports in the RNR, maybe we could address
> > your problem by adding a check that the specified frequency is a valid
> > channel using e.g. ieee80211_freq_to_chan?
> > 
> I thought about it but then there are two many combinations to deal
> with here.

Not sure what you mean with "too many combinations." However, that
proposal may not make sense anyway, considering we have this code in
wnm_nei_get_chan during RNR parsing:

		/*
		 * Some APs do not advertise correct operating class
		 * information. Try to determine the most likely operating
		 * frequency based on the channel number.
		 */
		if (chan >= 1 && chan <= 13)
			freq = 2407 + chan * 5;
		else if (chan == 14)
			freq = 2484;
		else if (chan >= 36 && chan <= 177)
			freq = 5000 + chan * 5;

I still think it would be good to know what the AP actually sends.
Otherwise we cannot properly discuss how a workaround might look like
and if it is possible to add one without regressing well-behaving
configurations.

Benjamin

> 
> > Benjamin
> > 
> > On Thu, 2025-10-09 at 17:21 -0700, Ashish Shukla wrote:
> > > 
> > > _______________________________________________
> > > Hostap mailing list
> > > Hostap at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/hostap
> 
> Date: Thu, 9 Oct 2025 16:54:29 -0700
> 
> Subject: [PATCH] WNM: Fallback to full scan when BTM contains incorrect
> 
>  channel info
> 
> 
> Some APs advertise incorrect channel info in BTM's reduced neighbor
> 
> report, causing partial scans to miss target BSS entries. Fall back to
> 
> full scan when detecting such frames to ensure all suggested BSS
> 
> entries are found. Note that this change has no impact on APs that send
> 
> properly formatted BTMs.
> 
> This also fixes a bug where 'has_6ghz' was set to true regardless of the
> 
> 'chan_supported' validation.
> 
> 
> Signed-off-by: Ashish Shukla <shukla.a at gmail.com>
> 
> 
> diff --git a/wpa_supplicant/wnm_sta.c b/wpa_supplicant/wnm_sta.c
> 
> index 9c8f37aeb..6a8a137ee 100644
> 
> --- a/wpa_supplicant/wnm_sta.c
> 
> +++ b/wpa_supplicant/wnm_sta.c
> 
> @@ -1358,7 +1358,7 @@ static void wnm_set_scan_freqs(struct
> wpa_supplicant *wpa_s)
> 
>   if (nei->preference_present && nei->preference == 0)
> 
>   continue;
> 
> 
> 
> - if (nei->freq <= 0) {
> 
> + if (nei->freq <= 0 || !chan_supported(wpa_s, nei->freq)) {
> 
>   wpa_printf(MSG_DEBUG,
> 
>     "WNM: Unknown neighbor operating frequency for "
> 
>     MACSTR " - scan all channels",
> 
> @@ -1367,9 +1367,7 @@ static void wnm_set_scan_freqs(struct
> wpa_supplicant *wpa_s)
> 
>   wpa_s->next_scan_freqs = NULL;
> 
>   return;
> 
>   }
> 
> - if (chan_supported(wpa_s, nei->freq))
> 
> - int_array_add_unique(&wpa_s->next_scan_freqs,
> 
> -     nei->freq);
> 
> + int_array_add_unique(&wpa_s->next_scan_freqs, nei->freq);
> 
>   has_6ghz |= is_6ghz_freq(nei->freq);
> 
>   }
> 
>