net80211: log possible "ghost beacons" during a scan

[bz]

Summary

In some circumstances we are seeing multiple beacons from the same BSSID
during a scan run, which is fine, especially with offloaded scans.

The problem is that at times one of them is reported to be on an entirely
wrong channel and usually with an off RSSI. I call these "ghost beacons".
When this happens it would (currently; in some cases) overwrite the
previous, correct, beacons for that BSSID and we might try to connect
on a wrong channel.

In my case this happens as the TX power vs. distance is high. Lowering
the TX power on the AP these "ghost beacons" disappear.

There are possible ways to possibly filter some of these out based on IEs
but we are not doing that in all cases. That is something to be looked
into in the future. The other possibility is to drop the one with the
supposedly off RSSI but we need consistently correct rssi values first.

For now log each and every one of the other channel duplicates for the
same BSSID in the same scan run. If people report too much noise in the
log, then we can hide this behind a wlandebug options but currently (at
least until we can filter properly) let people know about this as we have
too many reports of people not gettin onto 5Ghz and I am not sure if this
is related.

Reports in the kernel message buffer (dmesg) will look like:
wlan0: BSSID 02:04:06:08:13:57 already seen during this scan on chan 100 (se_rssi: -39), now chan 36 (rssi: -89)

Reported by: avg (rtwn), bz (iwlwifi)
Discussed at: https://lists.freebsd.org/archives/freebsd-wireless/2025-August/003688.html

		Message-ID: <[e-mail]>

MFC after: 3 days

[bz]

@adrian any concerns? The only concern I have is that with bgscans we might see a log entry every 5(?) minutes?

[bz]

If there's no feedback I'll put it into main Tuesday 16th UTC time. I want to make it ALPHA3 as we still have too many people with trouble on 5Ghz.

[avg]

I never really worked with code in this area, but the change looks good to me.

[adrian]

So, the DSPARAMS one is in ieee80211_parse_beacon(), look for IEEE80211_ELEMID_FHPARAMS and IEEE80211_ELEMID_DSPARAMS .

We likely can add some logic here for HTINFO and VHTINFO to figure out the base channel too?

[adrian]

In D52492#1199444, @bz wrote:

@adrian any concerns? The only concern I have is that with bgscans we might see a log entry every 5(?) minutes?

It's likely gonna log more with some other devices. Heh. :-)

[bz]

In D52492#1199848, @adrian wrote:

So, the DSPARAMS one is in ieee80211_parse_beacon(), look for IEEE80211_ELEMID_FHPARAMS and IEEE80211_ELEMID_DSPARAMS .

We likely can add some logic here for HTINFO and VHTINFO to figure out the base channel too?

I found the DSPARAMS but it took me a callgraph to check until I found when/if we would ditch them; we are checking them for elsewhere but I am not even sure we can get there. And it's mostly there to see if we can do the filtering before the logging so we have better user feedback.

[bz]

In D52492#1199853, @adrian wrote:

In D52492#1199444, @bz wrote:

@adrian any concerns? The only concern I have is that with bgscans we might see a log entry every 5(?) minutes?

It's likely gonna log more with some other devices. Heh. :-)

In theory it should not log anything. Should I hide it under wlandebug +scan?