Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Klaus Mueller <kmueller@justmail.de>
Subject: RTL8821CE: CTRL-EVENT-BEACON-LOSS and connection loss
To:     linux-wireless@vger.kernel.org
Message-ID: <e0de2157-c06e-c327-e969-d32cb21daf40@justmail.de>
Date:   Fri, 25 Dec 2020 11:55:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hello!

I'm having a
04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE
802.11ac PCIe Wireless Network Adapter
        Subsystem: AzureWave Device 3041
        Flags: bus master, fast devsel, latency 0, IRQ 71
        I/O ports at d000 [size=256]
        Memory at f7600000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [148] Device Serial Number xxxx...
        Capabilities: [158] Latency Tolerance Reporting
        Capabilities: [160] L1 PM Substates
        Capabilities: [170] Precision Time Measurement
        Capabilities: [17c] Vendor Specific Information: ID=0003 Rev=1
Len=054 <?>

or PCI-IDs
04:00.0 0280: 10ec:c821
        Subsystem: 1a3b:3041

It's running in 2.4 GHz / 40 MHz / Station EAPTLS / WPA-EAP-SHA256 mode.
wpa_supplicant 2.9 / no networkmanager. Kernel version is 5.10.1.


What are the problems?
- lots of "CTRL-EVENT-BEACON-LOSS" entries in wpa_supplicant.log
- very often loosing connection (CTRL-EVENT-DISCONNECTED)


There are 3 drivers:
[1] https://github.com/tomaspinho/rtl8821ce
[2] Driver in Kernel 5.10.1 (not really considered)
[3] Driver from https://github.com/lwfinger/rtw88

Throughput is measured using netperf.


Let's go into details. I will distinguish roughly two situations: very
good and mostly bad radio reception condition.


1. Very good radio reception condition
--------------------------------------
(~ 1 m distance between STA and AP and nothing in between).

=> no problem. Driver [1] and [3] are working as they should. Throughput
is about 12 MiB/s Rx and 13 MiB/s with both drivers.

on idle mode:
# iw dev wlan0 scan | egrep "signal|freq|SSID:"
        freq: 2412
        signal: -21.00 dBm
        SSID: mysta

on load: ~ -2[23] dBm


2. Mostly bad radio reception conditions
-----------------------------------------
Driver [1] doesn't work at all or pretty bad.
Driver [3] connects pretty fast (mostly as normal).

directly after reboot under bad conditions
# iw dev wlan0 scan | egrep "signal|freq|SSID:"
        freq: 2412
        signal: -7[268].00 dBm
        SSID: mysta

=> No "problems" can be seen. Throughput is about 2 MiB/s.

Now, the notebook is taken to good radio reception condition. It
performs as expected - no problem.

Now, bringing back the notebook again to the bad conditions:


# iw dev wlan0 scan | egrep "signal|freq|SSID:"
        freq: 2412
        signal: -25.00 dBm
        SSID: mysta

=> Driver doesn't realize changed conditions! Frequent
CTRL-EVENT-BEACON-LOSS events are coming up. If you set up a ping, the
CTRL-EVENT-BEACON-LOSS events (mostly) disappear now. During netperf,
they are disappearing completely. Switching off netperf and ping, the
CTRL-EVENT-BEACON-LOSS events are coming up again and even complete
connection loss appears.

Loosing connection at this point is fatal, because reconnection is very
hard and a connection is lost again after few seconds. Therefore, you
have to bring the notebook back again to the good conditions to get the
connection working again.

=> The driver doesn't seem to recognize the bad signal strength!


Conclusion at the moment:
=========================

- Driver seems to always remember best ever seen signal quality and
ignores reduced quality.
- Power save seems not to be the problem (I can see BEACON_LOSS events
with or without power management enabled).
- Driver doesn't like idle mode on bad conditions if it saw better
conditions before. As long as there is load on the device, the
connection persists and no or seldom CTRL-EVENT-BEACON-LOSS events can
be seen. If there is no more traffic, CTRL-EVENT-BEACON-LOSS events are
coming up frequently and the connection will be lost after more or less
short time.


I would be glad if you could find a solution. Don't hesitate if you have
further questions. I've no problem to test some patches.


Thanks
Klaus