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

[Ashish Shukla]

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.
> 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.

> 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.
> 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.

> 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);

  }



-- 

2.34.1