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.
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.
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).
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.
--
Andriy Gapon
