Re: rtwn/rtl8821au: strange issue with 5GHz channels

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