Bug 83641 - RTL8723BE realtek wifi chipset Frequent Disconnection
Summary: RTL8723BE realtek wifi chipset Frequent Disconnection
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
Depends on:
Reported: 2014-09-01 05:35 UTC by Rohit
Modified: 2018-11-03 17:32 UTC (History)
13 users (show)

See Also:
Kernel Version: 3.13.0-35-generic
Tree: Mainline
Regression: No

Proposed patch for rtl8723be weak signal (4.55 KB, patch)
2018-04-29 12:49 UTC, Larry Finger
Details | Diff

Description Rohit 2014-09-01 05:35:22 UTC
I have a RTL8723BE wifi chipset which frequently disconnects on my ubuntu 14.04. I have searched a lot of forums to get the solution, but I havent been able to find a working solution yet.

I found on the website https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1320070 that has a custom kernel, but that link is no longer active.

Is there a solution for this?
Comment 1 Larry Finger 2014-09-02 15:03:45 UTC
There is a new version of this driver at GitHub. You will need to have the package with the kernel headers installed.

git clone http://github.com/lwfinger/rtlwifi_new.git
cd rtlwifi_new
sudo make install

This version of the driver will be submitted for inclusion in kernel 3.18. I ran it for 39 hours with no disconnects.
Comment 2 Philip Kovac 2015-03-29 15:52:15 UTC
I may not be experiencing the same bug, but lwfinger's rtlwifi_new package doesn't seem to fix the problem entirely, only partially. I can now go several hours without the connection requiring a reset, but occasionally the connection will stop working despite NetworkManager etc still reporting the interface as associated. I've also added the 'fwlps=0' and 'ips=0' options to the module opts, with marginal improvement.

Laptop: HP Stream 11
Kernel version: mainline 3.19.0, lwfinger's rtlwifi_new 15f04b7

01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
        Subsystem: Hewlett-Packard Company Device 2231
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: I/O ports at 1000 [size=256]
        Region 2: Memory at 90400000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: rtl8723be
Comment 3 Che 2015-05-04 19:30:34 UTC
(In reply to Larry Finger from comment #1)
> There is a new version of this driver at GitHub. You will need to have the
> package with the kernel headers installed.
> git clone http://github.com/lwfinger/rtlwifi_new.git
> cd rtlwifi_new
> make
> sudo make install
> This version of the driver will be submitted for inclusion in kernel 3.18. I
> ran it for 39 hours with no disconnects.

I have updated kernel version 4.0 in my laptop. Wifi networks itself were not showing in my case. However I could resolve this issue by performing above steps.
Wondering why this issue still exist in latest version of kernel. 
I am using Ubuntu 14.04 64 bit os, laptop moderl lenovo z50-70
Comment 4 Larry Finger 2015-05-05 00:23:33 UTC
With Ubuntu, who knows. After wasting many hours trying to get out-of-kernel drivers to build after Ubuntu backported API changes, I have stopped supporting any Ubuntu kernels!!

My guess is that you did not have the firmware installed. Kernel 4.0 should be OK.
Comment 5 s.plaza 2015-05-12 20:34:14 UTC
I have the problem of loosing connection on my Lenovo M30-70, I am using Kernel 3.19.0-17-generic on Ubuntu 15.04.

I installed this rtlwifi_new driver (comment 1) and the connection is much better, but it still disconnect after a while. It always happens when dmesg shows the following line:

wlan0: AP 14:65:11:d7:9f:b6 changed bandwidth, new config is 2452 MHz, width 1 (2452/0 MHz)

The only thing that helps is to reconnect manually.
Is there any solution for this?

(I came from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1320070 my last comment was that this solution works stable, but now I realized this problem)
Comment 6 Raphaël Droz 2015-07-29 14:22:49 UTC
Same issue on the same chipset (Lenovo E555) with kernel 4.0
(using wireless-regdb 2014.11.18-1, case it would be related to bug #70881)
Comment 7 kernel 2016-03-26 10:57:01 UTC
I have the same issue with kernel 4.4, on a HP Stream 11.
For me fwlps=0 in the modprobe configuration seems to resolve the issue of frequent disconnects. It does not solve the issue of the wi-fi being completely unusable somtimes after waking from sleep (cannot see any networks).
Comment 8 radomirhadzic46 2018-03-01 20:53:42 UTC
I also have this issue with kernel 4.15. I opened the topic on Arch Linux Forums(https://bbs.archlinux.org/viewtopic.php?id=234933) and I suggest visiting it for more info.
Comment 9 Larry Finger 2018-03-01 21:19:57 UTC
There is a patch pending for kernel 4.16 and all stable kernels. It increases the L1 latency to 7. The patch is

 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index f9ccd13c79f9..e7bbbc95cdb1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1125,7 +1125,8 @@ static void _rtl8723be_enable_aspm_back_door(struct ieee80211_hw *hw)
 	/* Configuration Space offset 0x70f BIT7 is used to control L0S */
 	tmp8 = _rtl8723be_dbi_read(rtlpriv, 0x70f);
-	_rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7));
+	_rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7) |
+			     ASPM_L1_LATENCY << 3);
 	/* Configuration Space offset 0x719 Bit3 is for L1
 	 * BIT4 is for clock request

If your kernel does not have a definition for ASPM_L1_LATENCY, substitute 7 for it. It is defined in an earlier patch to fix rtl8821ae, but rtl8723be has the same problem on some platforms.
Comment 10 crocket 2018-04-25 11:18:57 UTC
Is it fixed?
Comment 11 Larry Finger 2018-04-25 15:40:39 UTC
The L1 latency fix is now in all kernels. It fixes the cases where the NIC loses contact with the AP.

Do you have the low signal problem? If so, then entering an ant_sel option is likely the fix you need.

In general, the driver does not have a disconnect problem, so I think it is fixed.
Comment 12 crocket 2018-04-26 10:17:10 UTC
rtl8723be on 3.16 ignored ant_sel.
rtl8723be on 3.15 picked up signals a lot better than on 3.9
Comment 13 Larry Finger 2018-04-26 16:32:14 UTC
It should not be surprising that 3.16 ignored ant_sel. That option was not added until 4.7.
Comment 14 crocket 2018-04-27 10:38:00 UTC
Larry Finger/ Ouch,... I meant 4.16, 4.15, and 4.9
Comment 15 Larry Finger 2018-04-27 16:22:12 UTC
4.16 does not ignore ant_sel. Why did you think that was the case? If it was from testing, keep in mind that the chip may need to have its power cycled for a new value to be accepted, thus a cold reboot may be needed when the ant_sel value is changed. For this to work, you need either to blacklist rtl8723be, or create an options file in /etc/modprobe.d/.
Comment 16 crocket 2018-04-28 08:27:44 UTC
Below is my test result. I shut down and booted again after changing ant_sel in /etc/modprobe.d/rtl8723be.conf

On linux 4.9.93,

with ant_sel=1, the WiFi signal goes up to 82
with ant_sel=2, the WiFi signal becomes low...

On linux 4.16.4

with ant_sel=1, the WiFi signal is 26~30
with ant_sel=2, there is no WiFi signal.
Comment 17 Larry Finger 2018-04-28 17:13:07 UTC
How are you getting your signal levels> What tool? Most applications report the signal in dBm, which is a negative number, thus a bigger magnitude is actually worse.

My recommended command is
sudo iw dev wlan0 scan | egrep "SSID|signal"

If your device is not wlan0, make the appropriate substitution.
Comment 18 crocket 2018-04-29 00:45:13 UTC
I used `wifish`. And, I also read signals from `iw dev wlo1 scan` and `wpa_cli scan && wpa_cli scan_results`.

-100 means zero signal. 0 means full signal.

Wifish calculates the signal with the equation, `100 + signal`.
Comment 19 crocket 2018-04-29 00:48:38 UTC
If you subtract 100 from wifih's signal number, you get dBm.
Comment 20 crocket 2018-04-29 00:48:48 UTC
wifih -> wifish
Comment 21 Larry Finger 2018-04-29 06:30:31 UTC
The ant_sel option was added by me to help support the people whose vendor stupidly sold computers with only a single antenna, but failed to correctly encode the EFUSE to indicate the connector they actually used. I wish I had never done that action. As they say, "no good deed goes unpunished".

The problem is that my actions were taken independently of the BT coexistence code, which is maintained by a Realtek group separate from the wifi group. As a result, the "correct" value for ant_sel changed. That is probably what happened in your case. That change is also compounded by the necessity for the chip to be powered off whenever the selected antenna is changed. To properly test the value, you must edit an option file in /etc/modprobe.d/ and do a full shutdown, and do a cold boot.

In the future, please report your signal strengths in dBm. That is the unit used by most people and tools.
Comment 22 crocket 2018-04-29 09:45:13 UTC
On linux 4.9 and 4.16, ant_sel had to be 1.
On linux 4.15, it had to be 2.

On linux 4.9, signal is ok.
On linux 4.15, signal is excellent.
On linux 4.16, signal is dismal.

Turning off and on doesn't solve linux 4.16's signal problem.

There's something wrong with linux 4.16.
Comment 23 Larry Finger 2018-04-29 12:49:54 UTC
Created attachment 275663 [details]
Proposed patch for rtl8723be weak signal

This patch may fix the 4.16 problem you see. If not, then I would appreciate your bisecting the problem.
Comment 24 crocket 2018-05-01 02:44:21 UTC
Fortunately, after applying the patch from comment 23 to linux 4.16.4, the WiFi signal strength is between -12dBm and -30dBm.
Comment 25 crocket 2018-05-01 02:45:34 UTC
Who screwed rtl8723be between 4.15 and 4.16.4?
Comment 26 Larry Finger 2018-05-01 03:52:55 UTC
The BT coexistence routines from a different Realtek group messed up the antenna select code. The Realtek driver group prepared that patch, which will be backported to stable kernels including 4.16.X. When is a question I cannot answer.

I am glad you get good signals with the patch.
Comment 27 crocket 2018-05-01 08:48:24 UTC
Is this issue about antenna select code? I want to be notified when antenna select code is fixed.
Comment 28 radomirhadzic46 2018-09-28 16:32:28 UTC
This issue returned, at least for me in 4.18.6. In 4.18.6 and subsequent versions of the kernel connection is good in the first few minutes (5 to 10). After a first few minutes, the connection degrades and becomes extremely weak I need to turn off and on NIC to regain it again for a few minutes. 4.18.5 works fine so I'm currently using it.
Comment 29 radomirhadzic46 2018-09-28 16:49:21 UTC
Actually, I take back that about 4.18.5: it doesn't work that well. The only difference is that 4.18.5 degrades connection, but usually not that much and automatically establishes good connection soon after degrading. Connection degrades in the intervals of 5-10 minutes too.
Comment 30 Larry Finger 2018-09-28 18:18:57 UTC
You need to do the antenna select test. Do the following:

sudo iw dev wlan0 scan | egrep "SSID|signal"

If your wifi device is not called wlan0, then make the appropriate change. Note the signal for your AP. If it is much more negative than -50, then your device has no antenna selected. How does this happen? The most common cause is that your computer vendor saved a few pennies by only installing one antenna, not two. That is OK; however, they incorrectly encoded the EFUSE, which is the information used by the driver to select the antenna.

If the signal is too low, then (as root) create a file named /etc/modprobe.d/50-rtl8723be.conf containing a line that contains "options rtl8723be ant_sel=1". Then shutdown the computer for at least 15 seconds. Do NOT do a warm reboot as the device may retain the old antenna selection value.

After the reboot, rerun the sudo iw command above. Did the signal improve a lot? If not, then change the ant_sel value from 1 to 2 and repeat.

Note that the original antenna selection code had bugs, and for most people, the correct value for the ant_sel value changed as I noted in comment #26.

As far as I know, the current antenna selection code will not be changed.
Comment 31 radomirhadzic46 2018-09-29 05:35:53 UTC
I tried what you told me but nothing improved. If ant_sel is set to 1 I can't connect at all, if it is set to 2 the signal is even worse (-86 compared to -80 normally).
Comment 32 Larry Finger 2018-09-29 17:08:45 UTC
The EFUSE must be encoded to use either antenna 1 or 2. Thus your result that both ant_sel of 1 or 2 is worse that the original cannot be right. I'm not sure that +/- 6 dBm is significant, particularly at the -80 level.

In any case, a signal of -80 dBm is far too low to maintain a stable connection. Assuming that your AP is not too far away, the signal should be much stronger. For example, my APs which are about 2m from my laptop have a strength of about -45 dBm in the 2G band. One operated by my neighbor is at least 20m away with a signal path through at least 4 exterior walls has a signal of -66 dBm, many orders of magnitude stronger than the one you report.

I have no idea what is wrong with your system.
Comment 33 crocket 2018-10-01 12:58:23 UTC
On linux 4.18.8, rtl8723be detects strong WiFi signals without ant_sel.
Comment 34 youling257 2018-11-03 17:25:45 UTC
8723bs have the same weak signal problem.
Comment 35 youling257 2018-11-03 17:32:15 UTC
on 4.19 kernel, 8723bs disconcert wlan -45 dbm, connect wlan -78dbm final -90 dbm.

# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -78.00 dBm
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -83.00 dBm
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -83.00 dBm
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -85.00 dBm
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -85.00 dBm
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -87.00 dBm
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -88.00 dBm
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -90.00 dBm
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -90.00 dBm

# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -45.00 dBm

Note You need to log in before you can comment on or make changes to this bug.