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

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

[Pablo Martínez Ríos]

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

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.
- 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".
- 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)
- 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.

Thanks,
Pablo.

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

[Ping-Ke Shih]

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.

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]

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

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

[Pablo Martínez Ríos]

Hi Ping-Ke, hi Bitterblue,

Thank you for the suggestions, and sorry for the delay. I ran most of
them; answers inline. Tests were done upstairs, in the usual spot,
unless stated otherwise.

> Is there any version working well to you?
> Could you bisect (use distro live image) which kernel can work to you?

Not so far. Debian 13 (6.12.107), Ubuntu 26.10 (7.3.0-9-generic) and
CachyOS (a 7.x kernel, exact version not recorded) behave the same. I
have not tested older kernels yet: old live ISOs may not boot here with
Secure Boot enabled. I could try disabling it to test it out if you think
it's worth it, but since I'm currently using Windows 11 with encrypted
drives, I'm not sure if that might cause any problems.

> I think it is worth to try putting closer.
> And, can you try another AP to see if anything different?

- Next to the router, 5 GHz works very well: about -45 dBm, link rates
  780/702 Mbit/s, ping about 2 ms, speed tests 350-440 Mbit/s.
- A phone hotspot on 5 GHz (ch 149, 80 MHz) at 1 m: 0% loss.
- I connected next to the router and carried the laptop upstairs while
  logging once per second. The signal went from -45 to about -78 dBm;
  pings were lost only when it reached about -77 dBm, and "tx failed"
  went from 1 to 8 within 5 s. After that the association stayed up
  (ping about 2 ms). Reconnecting to the same 5 GHz BSS from that spot
  fails every time (authentication timeouts).
- Windows 11 on the same laptop in the same spot connects to that BSS
  (RSSI -76 to -81 dBm as reported by Windows, 80/80 pings, 3-9 ms).

> How can you prove "no authentication response is ever received"?
> Can AP ack the auth? I mean that might be a TX side problem.

I cannot prove it; that sentence was an inference. I tested with a
second (monitor) interface on the same card (Ubuntu 26.10, 7.3.0-9):

1) Beacons: with the station interface down and mon0 fixed on channel
   36 (20 MHz, no HT), I receive 194 and 196 beacons of the AP in 20 s
   (about 195 expected), mean -75 dBm. So RX is fine.
2) In that state I injected 100 probe requests and 100 open-system
   authentication frames from my MAC to the AP: it ACKed about 100/100
   of each and answered them (many retransmitted answers, since mon0
   does not ACK them). The same on 2.4 GHz and next to the router.
3) With mon0 at 40 MHz (center 5190) or 80 MHz (center 5210) and
   everything else equal, the AP did not ACK or answer any of the 100
   probes or 100 authentication frames, while its beacons were still
   received (99-100 of about 100).
4) I set the router's 5 GHz width to 20 MHz (it advertises no
   secondary channel). Station-mode authentication still failed.
5) Station mode also fails on 2.4 GHz at certain times of day (e.g.
   with NetworkManager on Nov 8 at 13:14, and with plain "iw connect"
   open authentication on Nov 11 at 10:49), although on Nov 8 at 14:05
   injected frames on 2.4 GHz were ACKed 100/100. So from the same spot,
   injected frames at 20 MHz are ACKed, but authentication from the
   station interface is not, in both bands.

I do not know whether (3) is a monitor-mode artifact or related to the
failure. Is there something in the station-mode TX path (per-bandwidth
TX power, rates, RF configuration for this RFE) that differs from
injection? If you tell me which debug output or capture you would like
to see, I can collect it.

> For this case, "iw dev wlo1 set power_save off" should help.
> How about the loss rate comparing to power_save on? Almost the same?

Almost the same. In on/off pairs (2.4 GHz upstairs, 2.4 GHz next to the
router, and the 5 GHz hotspot) there was 0% loss in every run with
either setting. "firmware failed to leave lps state" appeared only in
some runs with power_save on and never in runs with it off. My earlier
54% figure came from a day when the 2.4 GHz link was bad for other
reasons, so please ignore it as evidence about power_save.

> Have you tested with disabling Bluetooth, since this is a combo chip?

Partially: I unloaded btusb (the bluetooth core stayed loaded because
other modules use it). 2.4 GHz was unchanged and 5 GHz upstairs still
fails. I do not know whether the BT side of the chip stays powered.

> You can add a printk to print the type of your RTL8822BE.

Thanks to Bitterblue's hint: the Ubuntu kernel has the rtw88 debugfs,
and coex_info reports "Mech/ RFE = Shared/ 5", so it is RFE type 5, one
of the supported types. I did not keep the dumps; I can collect
coex_info, phy_info and tx_pwr_tbl again if useful. I could not use the
edcca_enable switch: opening it fails with "Operation not permitted"
(probably kernel lockdown because of Secure Boot).

Corrections to my first message: the "wpa-psk" profile against the
router in WPA2/WPA3 mode actually used SAE in my logs. I can only say
the 5 GHz failure happens with the router set to WPA/WPA2 (Oct 31) and
to WPA2/WPA3. Also, the 2.4 GHz link varies a lot with the time of day
(it worked on the evenings of Nov 5 and 7, but not at other times,
possibly because of a strong nearby 2.4 GHz AP), so please treat
"Problem 2" as unreliable. The 5 GHz failure upstairs is reproducible.

Thanks,
Pablo

El mié, 4 nov 2026 a las 11:45, Bitterblue Smith
(<rtl8821cerfe2@gmail.com>) escribió:
>
> 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

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]

On 11/11/2026 12:15, Pablo Martínez Ríos wrote:
> Hi Ping-Ke, hi Bitterblue,
> 
> Thank you for the suggestions, and sorry for the delay. I ran most of
> them; answers inline. Tests were done upstairs, in the usual spot,
> unless stated otherwise.
> 
>> Is there any version working well to you?
>> Could you bisect (use distro live image) which kernel can work to you?
> 
> Not so far. Debian 13 (6.12.107), Ubuntu 26.10 (7.3.0-9-generic) and
> CachyOS (a 7.x kernel, exact version not recorded) behave the same. I
> have not tested older kernels yet: old live ISOs may not boot here with
> Secure Boot enabled. I could try disabling it to test it out if you think
> it's worth it, but since I'm currently using Windows 11 with encrypted
> drives, I'm not sure if that might cause any problems.
> 
>> I think it is worth to try putting closer.
>> And, can you try another AP to see if anything different?
> 
> - Next to the router, 5 GHz works very well: about -45 dBm, link rates
>   780/702 Mbit/s, ping about 2 ms, speed tests 350-440 Mbit/s.

[...]

>> You can add a printk to print the type of your RTL8822BE.
> 
> Thanks to Bitterblue's hint: the Ubuntu kernel has the rtw88 debugfs,
> and coex_info reports "Mech/ RFE = Shared/ 5", so it is RFE type 5, one

"Shared" indicates that your card has only one antenna, but I don't
think that's likely. You could not have 440 Mbps with just one antenna.

This comes from a byte in the chip's efuse. Maybe this byte is undefined
(0xff) in your chip, which would explain why it says "Shared". Here is
a patch to show the raw values:

diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
index 7c178ed63f45..92fd410c15cf 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
@@ -46,6 +46,9 @@ static int rtw8822b_read_efuse(struct rtw_dev *rtwdev, u8 *log_map, u8 *phy_map)
 
 	map = (struct rtw8822b_efuse *)log_map;
 
+	print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1,
+		       log_map, efuse->logical_size, true);
+
 	efuse->usb_mode_switch = u8_get_bits(map->usb_mode, BIT(7));
 	efuse->rfe_option = map->rfe_option;
 	efuse->rf_board_option = map->rf_board_option;

> of the supported types. I did not keep the dumps; I can collect
> coex_info, phy_info and tx_pwr_tbl again if useful. I could not use the
> edcca_enable switch: opening it fails with "Operation not permitted"
> (probably kernel lockdown because of Secure Boot).
> 
> Corrections to my first message: the "wpa-psk" profile against the
> router in WPA2/WPA3 mode actually used SAE in my logs. I can only say
> the 5 GHz failure happens with the router set to WPA/WPA2 (Oct 31) and
> to WPA2/WPA3. Also, the 2.4 GHz link varies a lot with the time of day
> (it worked on the evenings of Nov 5 and 7, but not at other times,
> possibly because of a strong nearby 2.4 GHz AP), so please treat
> "Problem 2" as unreliable. The 5 GHz failure upstairs is reproducible.
> 
> Thanks,
> Pablo
> 
> El mié, 4 nov 2026 a las 11:45, Bitterblue Smith
> (<rtl8821cerfe2@gmail.com>) escribió:
>>
>> 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

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

[Pablo Martínez Ríos]

Hi Bitterblue, hi Ping-Ke,

I built the Debian 6.12.107 rtw88 sources with your print_hex_dump patch
(nothing else changed) and loaded the modules. This is the raw efuse
logical map of the RTL8822BE, with my MAC address (0xd0-0xd5) replaced
by xx. 0x70-0xaf is all 0xff, and I left out 0x100 and above:

00000000: 29 81 00 3c 09 10 0b 00 ac 04 a4 35 10 03 30 0b
00000010: 2c 2c 2d 2d 2d 2d 2c 2c 2c 2c 2c 02 00 00 ff ff
00000020: ff ff 27 27 27 27 27 27 27 29 2a 2b 2a 2a 2c 2e
00000030: 02 00 ff ff 00 ff 0c 00 ff ff 29 29 29 29 29 29
00000040: 29 29 29 29 29 02 00 00 ff ff ff ff 26 25 25 23
00000050: 23 23 23 23 25 25 23 23 23 23 02 00 ff ff 00 ff
00000060: 0c 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
000000b0: ff ff ff ff ff ff ff ff 7f 21 1d 00 ff ff ff ff
000000c0: ff 29 00 11 00 00 00 00 00 ff 05 ff ff ff ff ff
000000d0: xx xx xx xx xx xx ec 10 22 b8 3c 10 1b 83 c3 ff
000000e0: 80 8d 80 08 00 00 11 3c 27 00 10 20 01 22 b8 fe
000000f0: ff 4c e0 00 04 0c 00 80 02 00 80 02 00 00 f0 00

With the struct layout of rtw8822b_efuse (channel_plan at 0xb8):
  0xb8 channel_plan = 0x7f, xtal_k = 0x21, thermal_meter = 0x1d
  0xbc pa_type = 0xff, lna_type_2g/5g = 0xff
  0xc1 rf_board_option = 0x29, rf_feature_option = 0x00
  0xc3 rf_bt_setting = 0x11
  0xc9 rf_antenna_option = 0xff, 0xca rfe_option = 0x05
  country_code = ff ff
The PCI ids appear at 0xd6-0xdd (10ec:b822, subsystem 103c:831b), so the
offsets look right.

So rfe_option is 5, as coex_info said. If "Shared" is derived from
rf_bt_setting (bit 0 of 0x11 is set), that byte is programmed, not 0xff.
rf_antenna_option is 0xff, so if that is the byte you meant, it is
indeed undefined. Which byte does coex_info use for "Shared"? And is
0xff in rf_antenna_option / pa_type / lna_type normal for RFE 5?

I understood "Shared" as the Bluetooth sharing an antenna with the
WLAN (not that the WLAN has a single one), which would fit 2 spatial
streams working, but I may be wrong.

What would you like me to try next?

Thanks,
Pablo

El mié, 11 nov 2026 a las 12:58, Bitterblue Smith
(<rtl8821cerfe2@gmail.com>) escribió:
>
> On 11/11/2026 12:15, Pablo Martínez Ríos wrote:
> > Hi Ping-Ke, hi Bitterblue,
> >
> > Thank you for the suggestions, and sorry for the delay. I ran most of
> > them; answers inline. Tests were done upstairs, in the usual spot,
> > unless stated otherwise.
> >
> >> Is there any version working well to you?
> >> Could you bisect (use distro live image) which kernel can work to you?
> >
> > Not so far. Debian 13 (6.12.107), Ubuntu 26.10 (7.3.0-9-generic) and
> > CachyOS (a 7.x kernel, exact version not recorded) behave the same. I
> > have not tested older kernels yet: old live ISOs may not boot here with
> > Secure Boot enabled. I could try disabling it to test it out if you think
> > it's worth it, but since I'm currently using Windows 11 with encrypted
> > drives, I'm not sure if that might cause any problems.
> >
> >> I think it is worth to try putting closer.
> >> And, can you try another AP to see if anything different?
> >
> > - Next to the router, 5 GHz works very well: about -45 dBm, link rates
> >   780/702 Mbit/s, ping about 2 ms, speed tests 350-440 Mbit/s.
>
> [...]
>
> >> You can add a printk to print the type of your RTL8822BE.
> >
> > Thanks to Bitterblue's hint: the Ubuntu kernel has the rtw88 debugfs,
> > and coex_info reports "Mech/ RFE = Shared/ 5", so it is RFE type 5, one
>
> "Shared" indicates that your card has only one antenna, but I don't
> think that's likely. You could not have 440 Mbps with just one antenna.
>
> This comes from a byte in the chip's efuse. Maybe this byte is undefined
> (0xff) in your chip, which would explain why it says "Shared". Here is
> a patch to show the raw values:
>
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> index 7c178ed63f45..92fd410c15cf 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> @@ -46,6 +46,9 @@ static int rtw8822b_read_efuse(struct rtw_dev *rtwdev, u8 *log_map, u8 *phy_map)
>
>         map = (struct rtw8822b_efuse *)log_map;
>
> +       print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1,
> +                      log_map, efuse->logical_size, true);
> +
>         efuse->usb_mode_switch = u8_get_bits(map->usb_mode, BIT(7));
>         efuse->rfe_option = map->rfe_option;
>         efuse->rf_board_option = map->rf_board_option;
>
> > of the supported types. I did not keep the dumps; I can collect
> > coex_info, phy_info and tx_pwr_tbl again if useful. I could not use the
> > edcca_enable switch: opening it fails with "Operation not permitted"
> > (probably kernel lockdown because of Secure Boot).
> >
> > Corrections to my first message: the "wpa-psk" profile against the
> > router in WPA2/WPA3 mode actually used SAE in my logs. I can only say
> > the 5 GHz failure happens with the router set to WPA/WPA2 (Oct 31) and
> > to WPA2/WPA3. Also, the 2.4 GHz link varies a lot with the time of day
> > (it worked on the evenings of Nov 5 and 7, but not at other times,
> > possibly because of a strong nearby 2.4 GHz AP), so please treat
> > "Problem 2" as unreliable. The 5 GHz failure upstairs is reproducible.
> >
> > Thanks,
> > Pablo
> >
> > El mié, 4 nov 2026 a las 11:45, Bitterblue Smith
> > (<rtl8821cerfe2@gmail.com>) escribió:
> >>
> >> 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
>

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]

On 11/11/2026 23:00, Pablo Martínez Ríos wrote:
> Hi Bitterblue, hi Ping-Ke,
> 
> I built the Debian 6.12.107 rtw88 sources with your print_hex_dump patch
> (nothing else changed) and loaded the modules. This is the raw efuse
> logical map of the RTL8822BE, with my MAC address (0xd0-0xd5) replaced
> by xx. 0x70-0xaf is all 0xff, and I left out 0x100 and above:
> 
> 00000000: 29 81 00 3c 09 10 0b 00 ac 04 a4 35 10 03 30 0b
> 00000010: 2c 2c 2d 2d 2d 2d 2c 2c 2c 2c 2c 02 00 00 ff ff
> 00000020: ff ff 27 27 27 27 27 27 27 29 2a 2b 2a 2a 2c 2e
> 00000030: 02 00 ff ff 00 ff 0c 00 ff ff 29 29 29 29 29 29
> 00000040: 29 29 29 29 29 02 00 00 ff ff ff ff 26 25 25 23
> 00000050: 23 23 23 23 25 25 23 23 23 23 02 00 ff ff 00 ff
> 00000060: 0c 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 000000b0: ff ff ff ff ff ff ff ff 7f 21 1d 00 ff ff ff ff
> 000000c0: ff 29 00 11 00 00 00 00 00 ff 05 ff ff ff ff ff
> 000000d0: xx xx xx xx xx xx ec 10 22 b8 3c 10 1b 83 c3 ff
> 000000e0: 80 8d 80 08 00 00 11 3c 27 00 10 20 01 22 b8 fe
> 000000f0: ff 4c e0 00 04 0c 00 80 02 00 80 02 00 00 f0 00
> 
> With the struct layout of rtw8822b_efuse (channel_plan at 0xb8):
>   0xb8 channel_plan = 0x7f, xtal_k = 0x21, thermal_meter = 0x1d
>   0xbc pa_type = 0xff, lna_type_2g/5g = 0xff
>   0xc1 rf_board_option = 0x29, rf_feature_option = 0x00
>   0xc3 rf_bt_setting = 0x11
>   0xc9 rf_antenna_option = 0xff, 0xca rfe_option = 0x05
>   country_code = ff ff
> The PCI ids appear at 0xd6-0xdd (10ec:b822, subsystem 103c:831b), so the
> offsets look right.
> 
> So rfe_option is 5, as coex_info said. If "Shared" is derived from
> rf_bt_setting (bit 0 of 0x11 is set), that byte is programmed, not 0xff.
> rf_antenna_option is 0xff, so if that is the byte you meant, it is
> indeed undefined. Which byte does coex_info use for "Shared"? And is
> 0xff in rf_antenna_option / pa_type / lna_type normal for RFE 5?

That looks normal. "Shared" comes from bit 0 of rf_bt_setting.

> 
> I understood "Shared" as the Bluetooth sharing an antenna with the
> WLAN (not that the WLAN has a single one), which would fit 2 spatial
> streams working, but I may be wrong.

Yes, that's probably correct. I guess "Shared" means one antenna only
for the chips with one spatial stream.

> 
> What would you like me to try next?

I don't have other ideas.

> 
> Thanks,
> Pablo
> 
> El mié, 11 nov 2026 a las 12:58, Bitterblue Smith
> (<rtl8821cerfe2@gmail.com>) escribió:
>>
>> On 11/11/2026 12:15, Pablo Martínez Ríos wrote:
>>> Hi Ping-Ke, hi Bitterblue,
>>>
>>> Thank you for the suggestions, and sorry for the delay. I ran most of
>>> them; answers inline. Tests were done upstairs, in the usual spot,
>>> unless stated otherwise.
>>>
>>>> Is there any version working well to you?
>>>> Could you bisect (use distro live image) which kernel can work to you?
>>>
>>> Not so far. Debian 13 (6.12.107), Ubuntu 26.10 (7.3.0-9-generic) and
>>> CachyOS (a 7.x kernel, exact version not recorded) behave the same. I
>>> have not tested older kernels yet: old live ISOs may not boot here with
>>> Secure Boot enabled. I could try disabling it to test it out if you think
>>> it's worth it, but since I'm currently using Windows 11 with encrypted
>>> drives, I'm not sure if that might cause any problems.
>>>
>>>> I think it is worth to try putting closer.
>>>> And, can you try another AP to see if anything different?
>>>
>>> - Next to the router, 5 GHz works very well: about -45 dBm, link rates
>>>   780/702 Mbit/s, ping about 2 ms, speed tests 350-440 Mbit/s.
>>
>> [...]
>>
>>>> You can add a printk to print the type of your RTL8822BE.
>>>
>>> Thanks to Bitterblue's hint: the Ubuntu kernel has the rtw88 debugfs,
>>> and coex_info reports "Mech/ RFE = Shared/ 5", so it is RFE type 5, one
>>
>> "Shared" indicates that your card has only one antenna, but I don't
>> think that's likely. You could not have 440 Mbps with just one antenna.
>>
>> This comes from a byte in the chip's efuse. Maybe this byte is undefined
>> (0xff) in your chip, which would explain why it says "Shared". Here is
>> a patch to show the raw values:
>>
>> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
>> index 7c178ed63f45..92fd410c15cf 100644
>> --- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
>> +++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
>> @@ -46,6 +46,9 @@ static int rtw8822b_read_efuse(struct rtw_dev *rtwdev, u8 *log_map, u8 *phy_map)
>>
>>         map = (struct rtw8822b_efuse *)log_map;
>>
>> +       print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1,
>> +                      log_map, efuse->logical_size, true);
>> +
>>         efuse->usb_mode_switch = u8_get_bits(map->usb_mode, BIT(7));
>>         efuse->rfe_option = map->rfe_option;
>>         efuse->rf_board_option = map->rf_board_option;
>>
>>> of the supported types. I did not keep the dumps; I can collect
>>> coex_info, phy_info and tx_pwr_tbl again if useful. I could not use the
>>> edcca_enable switch: opening it fails with "Operation not permitted"
>>> (probably kernel lockdown because of Secure Boot).
>>>
>>> Corrections to my first message: the "wpa-psk" profile against the
>>> router in WPA2/WPA3 mode actually used SAE in my logs. I can only say
>>> the 5 GHz failure happens with the router set to WPA/WPA2 (Oct 31) and
>>> to WPA2/WPA3. Also, the 2.4 GHz link varies a lot with the time of day
>>> (it worked on the evenings of Nov 5 and 7, but not at other times,
>>> possibly because of a strong nearby 2.4 GHz AP), so please treat
>>> "Problem 2" as unreliable. The 5 GHz failure upstairs is reproducible.
>>>
>>> Thanks,
>>> Pablo
>>>
>>> El mié, 4 nov 2026 a las 11:45, Bitterblue Smith
>>> (<rtl8821cerfe2@gmail.com>) escribió:
>>>>
>>>> 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
>>

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

[Luka Gejak]

Hi Pablo and Bitterblue,

On November 12, 2026 4:50:55 PM GMT+01:00, Bitterblue Smith
<rtl8821cerfe2@gmail.com> wrote:
>On 11/11/2026 23:00, Pablo Martínez Ríos wrote:
>>
>> What would you like me to try next?
>
> I don't have other ideas.

I had a look and I think this could be EDCCA. With the country set to ES,
rtw88 runs the ETSI adaptivity mode. The RTL8822B firmware doesn't do that
part itself, so the driver sets the energy detect threshold in
rtw8822b_adaptivity():

        l2h = min_t(s8, igi, dm_info->l2h_th_ini);
        h2l = l2h - EDCCA_L2H_H2L_DIFF;

l2h_th_ini is 36 for ETSI, so the threshold follows IGI down. Before the
association rtw88 has no station entry yet, so the DIG lets IGI drop to
its 0x1c floor. That gives L2H 28 and H2L 21, nominally -82 and -89 dBm.
As long as the energy on the channel stays above that, the MAC holds every
frame, so the authentication frames may never leave the card.

As far as I can see that fits most of what you measured. On 40 and 80 MHz
the receiver takes in the whole channel, so it likely sees more noise and
more traffic from other networks than on 20 MHz. That would explain why
the AP only ACKed your injected frames on 20 MHz.

Once associated, the DIG raises IGI at a much lower false alarm count, so
the threshold can sit higher. That may be why the link survived the walk
upstairs. To leave LPS the firmware also needs a null frame ACKed by the
AP, so the "firmware failed to leave lps state" messages could come from
the same thing.

Your kernels use the same rule on 2.4 GHz, which might explain the bad
times of day there as well. Josef already relaxed it for 2.4 GHz in
rtw-next with commit b0435910e47d.

The one result that doesn't fit is 00. With 00 the driver uses the normal
threshold, which never goes below 48 (nominally -62 dBm), so I would
expect 00 to work from upstairs. Could you check "iw reg get" right before
you connect, once with 00 and once with ES? After a connection the country
element of your router can switch it to ES.

Could you also try the patch below with ES set? On 5 GHz it uses a fixed
L2H of 45, nominally -65 dBm, which is 3 dB below the EN 301 893 level
over 20 MHz. It also carries Josef's 2.4 GHz change, so it should apply to
your 6.12 sources. If it helps, I will send it properly for rtw-next.

diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
--- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
@@ -1565,6 +1565,16 @@ static void rtw8822b_adaptivity(struct rtw_dev *rtwdev)
        if (dm_info->edcca_mode == RTW_EDCCA_NORMAL) {
                l2h = max_t(s8, igi + EDCCA_IGI_L2H_DIFF, EDCCA_TH_L2H_LB);
                h2l = l2h - EDCCA_L2H_H2L_DIFF_NORMAL;
+       } else if (rtwdev->regd.dfs_region == NL80211_DFS_ETSI &&
+                  rtwdev->hal.current_band_type == RTW_BAND_2G) {
+               /* follow the normal threshold, capped for EN 300 328 */
+               l2h = max_t(s8, igi + EDCCA_IGI_L2H_DIFF, EDCCA_TH_L2H_LB);
+               l2h = min_t(s8, l2h, RTW8822B_EDCCA_ETSI_2G);
+               h2l = l2h - EDCCA_L2H_H2L_DIFF;
+       } else if (rtwdev->regd.dfs_region == NL80211_DFS_ETSI &&
+                  rtwdev->hal.current_band_type == RTW_BAND_5G) {
+               l2h = RTW8822B_EDCCA_ETSI_5G;
+               h2l = l2h - EDCCA_L2H_H2L_DIFF;
        } else {
                l2h = min_t(s8, igi, dm_info->l2h_th_ini);
                h2l = l2h - EDCCA_L2H_H2L_DIFF;
diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.h b/drivers/net/wireless/realtek/rtw88/rtw8822b.h
--- a/drivers/net/wireless/realtek/rtw88/rtw8822b.h
+++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.h
@@ -149,6 +149,10 @@ _rtw_write32s_mask(struct rtw_dev *rtwdev, u32 addr, u32 mask, u32 data)
 #define GET_PHY_STAT_P1_RXSNR_B(phy_stat)                                      \
        le32_get_bits(*((__le32 *)(phy_stat) + 0x06), GENMASK(15, 8))

+/* nominally -60 dBm: 3 dB below the EN 300 328 level at 20 dBm e.i.r.p. */
+#define RTW8822B_EDCCA_ETSI_2G 50
+/* nominally -65 dBm: 3 dB below the EN 301 893 level over 20 MHz */
+#define RTW8822B_EDCCA_ETSI_5G 45
 #define RTW8822B_EDCCA_MAX     0x7f
 #define RTW8822B_EDCCA_SRC_DEF 1
 #define REG_HTSTFWT    0x800

Best regards,
Luka Gejak