Re: rtw88: RTL8822BE (10ec:b822) never authenticates on 5 GHz with a Huawei router; poor 2.4 GHz link; same hardware works fine on Windows

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 04/11/2026 03:33, Ping-Ke Shih wrote:
> Pablo Martínez Ríos <pabloriosmartinez@gmail.com> wrote:
>> Hello,
>>
>> I would like to report a problem with an RTL8822BE using rtw88_8822be.
>> The same card, in the same spot, works well on Windows, so I suspect a
>> driver/firmware issue rather than coverage. I am happy to run any tests
>> or try patches.
>>
>> HARDWARE / SOFTWARE
>> - Laptop: HP Pavilion 15-bc450ns (i5-8300H), BIOS F.32
>> - Card: Realtek RTL8822BE, PCI ID 10ec:b822 (04:00.0), HP subsystem.
>>   Both antenna cables are connected; "iw phy" reports available and
>>   configured antennas TX 0x3 / RX 0x3.
>> - Debian 13.7 live USB, kernel 6.12.107+deb13-amd64, firmware-realtek
>>   20250410-2, rtw88 firmware 27.2.0 (H2C 13)
>> - Same behaviour earlier on CachyOS (a recent 7.x kernel, exact version
>>   not recorded) and on an Ubuntu live session (26.10)
> 
> Is there any version working well to you?
> 
>> - Module parameters at defaults: disable_lps_deep=N, disable_aspm=N,
>>   support_bf=Y
>> - Router: ISP-supplied Huawei OptiXstar EG8145X6-10, separate SSIDs for
>>   2.4 GHz (ch 6, 20 MHz) and 5 GHz (ch 36, auto width). The router is
>>   one floor below the laptop, with a concrete slab in between.
> 
> I think it is worth to try putting closer.
> 
> And, can you try another AP to see if anything different?
> 
>>
>> PROBLEM 1: 5 GHz
>> Linux never authenticates. This repeats indefinitely:
>>
>>   wlo1: authenticate with 22:87:ec:xx:xx:08 (local address=90:32:4b:xx:xx:xx)
>>   wlo1: send auth to 22:87:ec:xx:xx:08 (try 1/3)
>>   wlo1: send auth to 22:87:ec:xx:xx:08 (try 2/3)
>>   wlo1: send auth to 22:87:ec:xx:xx:08 (try 3/3)
>>   wlo1: authentication with 22:87:ec:xx:xx:08 timed out
>>
>> - It fails with WPA2-PSK and with WPA3 (SAE), and with the router set to
>>   WPA/WPA2 TKIP+AES and to WPA2/WPA3 AES, so it fails at the 802.11
>>   authentication frame, before any SAE/EAPOL exchange.
>> - Same result with regulatory domain 00 and with "iw reg set ES".
>> - The BSS appears in scans (its beacons carry country IE ES), but no
>>   authentication response is ever received.
> 
> How can you prove "no authentication response is ever received" ?
> Can AP ack the auth? I mean that might be a TX side problem.
> 
>> - Windows 11 on the same laptop, same spot (Realtek driver
>>   2024.0.10.209): connects with WPA3-Personal, reported RSSI -76 to
>>   -81 dBm, 80/80 pings answered, 3-9 ms, link rate 260-292 Mbps as
>>   reported by Windows.
>>
>> PROBLEM 2: 2.4 GHz
>> - Linux associates, but the link is very poor: iw reports about -73 to
>>   -76 dBm, and the beacon loss counter rises about once per second
>>   (14 to 65 over roughly 2 minutes). Across 5 runs, ping to the router
>>   showed 0-54% loss and average RTT of 37-278 ms.
>> - Kernel messages: "rtw_8822be 0000:04:00.0: firmware failed to leave
>>   lps state" (several times), and once "failed to send h2c command".
> 
> For this case, "iw dev wlo1 set power_save off" should help.
> 
>> - The beacon signal average (-97 to -109 dBm) is far below the frame
>>   signal average (about -75 dBm). With a phone hotspot at -48 dBm both
>>   agree (-46). Occasionally signal readings of -100 to -112 dBm appear
>>   with the second chain at 0 while traffic continues.
>> - Windows, same spot: 60/60 pings, average 12 ms (max 157 ms).
>> - With a phone hotspot (2.4 GHz, ch 1, -48 dBm), Linux works well:
>>   rx 78 Mbit/s (VHT-MCS 8, NSS 1), tx 65 Mbit/s (MCS 7).
>>
>> TRIED WITHOUT EFFECT
>> - "iw dev wlo1 set power_save off" (one run had 54% ping loss)
> 
> How about the loss rate comparing to power_save on? Almost the same?
> 
>> - rtw88_pci disable_aspm=Y (lspci still showed "ASPM L1 Enabled"
>>   afterwards)
>> - WPA2 vs WPA3, regulatory domain 00 vs ES
>>
>> COULD NOT CHECK
>> /sys/kernel/debug/ieee80211/phy0/rtw88 does not exist on the Debian
>> kernel (presumably rtw88 debugfs is not enabled), so I could not read
>> tx_pwr_tbl, phy_info or coex_info, nor test the edcca_enable switch.
>> A single correctable PCIe error (BadDLLP) was logged once; the AER
>> counters were 0 later.
>>
>> QUESTIONS
>> Is this a known issue? Which additional data would be most useful (a
>> kernel with rtw88 debugfs, a debug_mask setting, a monitor-mode
>> capture)? I can provide full logs and test patches.
> 
> The kernel v5.3 or earlier support RTL8822BE. Could you bisect (use
> distro live image) which kernel can work to you? It would be easier
> to address problem. 
> 
> Have you tested with disabling Bluetooth, since this is a combo chip?
> 
> Another point is that rtw88 can only support these types:
> 
> static const struct rtw8822b_rfe_info rtw8822b_rfe_info[] = {
> 	[2] = I2GE5G_CCUT(efem),
> 	[3] = IFEM_EXT_CCUT(ifem),
> 	[5] = IFEM_EXT_CCUT(ifem),
> };
> 
> You can add a printk to print the type of your RTL8822BE.

On CachyOS you can get the RFE type from debugfs:

cat /sys/kernel/debug/ieee80211/phy*/rtw88/coex_info