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.
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?
Can you turn TX power down on th AP?
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.
/bz
--
Bjoern A. Zeeb r15:7
