On Fri, 29 Aug 2025, Andriy Gapon wrote:
On 28/08/2025 23:00, Bjoern A. Zeeb wrote:
On Thu, 28 Aug 2025, Andriy Gapon wrote:
On 19/08/2025 15:46, Andriy Gapon wrote:
This may be unsurprising becomes the adapter sees a wrong / strange
channel number comparing to what's configured on the AP. It's almost
always +4.
And only rarely it's the correct number. In those cases the connection
works.
E.g., right now:
$ ifconfig wlan0 scan | sort -t '' -k 1.66,1.67n | head -2
SSID/MESH ID BSSID CHAN RATE S:N INT
CAPS
HolyLan 7a:d2:94:80:1f:ec 153 54M -70:-95
100 EPS RSN BSSLOAD HTCAP VHTCAP VHTOPMODE VHTPWRENV WME
I've observed how a scan can get a wrong frequency / channel for an AP.
In this case the channel is very different (not +4) and I have no idea
what could the issue.
Evidence:
Aug 27 21:01:35 rock64b kernel: [78:d2:94:80:1f:ec] new probe_resp on chan
36 (bss chan 36) "ThePromisedLan" rssi 53 Aug 27 21:01:35 rock64b kernel:
[78:d2:94:80:1f:ec] caps 0x11 bintval 100 erp 0x0 country [UA 36-43,20
100-110,20 144,0 149-153,20] Aug 27 21:01:35 rock64b kernel:
[78:d2:94:80:1f:ec] new probe_resp on chan 36 (bss chan 36)
"ThePromisedLan" rssi 53 Aug 27 21:01:35 rock64b kernel:
[78:d2:94:80:1f:ec] caps 0x11 bintval 100 erp 0x0 country [UA 36-43,20
100-110,20 144,0 149-153,20] Aug 27 21:01:35 rock64b kernel:
[78:d2:94:80:1f:ec] new probe_resp on chan 36 (bss chan 36)
"ThePromisedLan" rssi 53 Aug 27 21:01:35 rock64b kernel:
[78:d2:94:80:1f:ec] caps 0x11 bintval 100 erp 0x0 country [UA 36-43,20
100-110,20 144,0 149-153,20] Aug 27 21:01:35 rock64b kernel:
[78:d2:94:80:1f:ec] new probe_resp on chan 36 (bss chan 36)
"ThePromisedLan" rssi 53 Aug 27 21:01:35 rock64b kernel:
[78:d2:94:80:1f:ec] caps 0x11 bintval 100 erp 0x0 country [UA 36-43,20
100-110,20 144,0 149-153,20]
Aug 27 21:01:38 rock64b kernel: [78:d2:94:80:1f:ec] new beacon on chan 132
(bss chan 132) "ThePromisedLan" rssi 9 Aug 27 21:01:38 rock64b kernel:
[78:d2:94:80:1f:ec] caps 0x11 bintval 100 erp 0x0 country [UA 36-43,20
100-110,20 144,0 149-153,20]
Aug 27 21:01:39 rock64b kernel: wlan0: macaddr bssid
chan rssi rate flag wep essid Aug 27 21:01:39 rock64b kernel: -
78:d2:94:80:1f:ec 78:d2:94:80:1f:ec 132 +49 54M ess wep
"ThePromisedLan"!
So, all messages are about the same AP (ThePromisedLan /
78:d2:94:80:1f:ec).
Initially, the scan saw some probe responses on the correct channel (36)
with strong signal (rssi 53). Later, after jumping many channels, the
scan saw a beacon for the same AP on a wrong channel (132) with much
weaker signal (rssi 9). But the last seen channel won.
Ghost beacons :) I just debugged that with iwlwifi 2-3 days ago. I
added logging to LinuxKPI as well initially because I suspected
something went wrong with SKBs etc. I have a feeling that this may be
the same problem why some people have trouble getting onto 5Ghz with
iwlwifi.
Oh, so I am not alone :-)
That beacon on the wrong channel is very puzzling.
What could it be?
Some problem on the AP side?
Or some issue with switching channels on the adapter side?
Or something in the environment? E.g., some spoofing / hacking equipment?
Do they go away when you move further away from the AP?Yes. As the main
channel signal gets weaker, the much weaker signal of the
wrong channel also gets weaker to the point where it completely disappears.
Can you turn TX power down on th AP?
Yes, I can do that too.Its current setting is 20 dBm / 100 mW, the default
and the maximum too.
Given mine is ocked down I only have high/middle/low and can hardly say
to what that resembles...
Another thing that I discovered is that if I change the channel width from 80
MHz down to 40 MHz (without changing anything else) the ghost beacons
completely disappear too.
That interessting. I cannot do that on that device; I could only force
the sta.
In my case the problem is that it was CH 100 (correct) and the ghost beacon
was on ch 36: 5500 - 5180 = 320
There's no support of 320 wide channels on 5Ghz due to no sufficiently contigous
spectrum.
I would assume we are more likely dealing with physics here.
What I found interesting is that we both discovered this within a few
days and I hadn't seen this in the years before.
Given iwlwifi seems to report scan results in 5Ghz high to low channels
my STA was always associated during boot before I would even see the
first ghost (but I also checked that I do see them if not assoc) I would
likely not have noticed in the last 20 days since that setup stands
where it stands. Also the ghosts for me always came in with the last
channel scanned. That said, apart from the channel they were valid;
content was the same, seq/timestamps got updated, ...
What also got my curiousity was that the AX210 monitor node next to it
would not see the ghosts nor did the phone with a brcm chipset. I wanted
to put a mediatek/linux sta there as well and a Realtek but shuffling
cards etc. is currently too intrusive in that case.
So, I guess that there could be a hardware or other -ware bug on the AP side
related to 80 MHz width.
FWIW, the AP is Netgear WAC104 re-flashed with OpenWRT (version 24.10.2).
If I am not mistaken you were CH 132 - CH 36, so even further apart than
I am. What's your chanlist ends? 36..173? (or that of the AP if you
can find out)?
How's the DFS requirement in UA?
I had a cheap 11be tri-band router here for dummy testing and when I
was close iwlwifi (but not a monitor node or my iphone next to the
laptop) would see beacons on a wrong channel in addition to the
correct one. They usually followed another beacon which was correct on
that channel.
I verified that these beacosn indeed came up from the firmware by
checking the RX dma buffers before much/any processing got done.
The moment I turned TX power on that AP for 5Ghz from Medium to Low
the Ghost beacons were gone. The AP chipsets is a QCA IPQ5322, the
firmware is a crippled openwrt locked down.
Interesting.
My AP has some MediaTek MT76* Wi-Fi chip.
I wonder if there is anything that we could on FreeBSD WiFi stack side to
work around such broken APs. E.g., if the same AP's beacons or responses are
seen on two channels then prefer a stronger one instead of the last scanned
one. Or some such heuristics. Or at least log something, so that a user
could be aware of the issue and could try to fix it on the AP side.
I was indeed thinking of filtering out the weaker one somehow but need to
sort the RSSI bits out first (D50928) and flush other work before I open
the next stack. I like the idea of logging duplicate BSSIDs on
different channels.
Need to make sure we do it over the same scan batch/check CSA/...
/bz
--
Bjoern A. Zeeb r15:7
