Bug 83641

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

(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

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.

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)

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)

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

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.

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.

Is it fixed?

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.

rtl8723be on 3.16 ignored ant_sel.
rtl8723be on 3.15 picked up signals a lot better than on 3.9

It should not be surprising that 3.16 ignored ant_sel. That option was not added until 4.7.

Larry Finger/ Ouch,... I meant 4.16, 4.15, and 4.9

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

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.

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.

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

If you subtract 100 from wifih's signal number, you get dBm.

wifih -> wifish

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.

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.

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.

Fortunately, after applying the patch from comment 23 to linux 4.16.4, the WiFi signal strength is between -12dBm and -30dBm.

Who screwed rtl8723be between 4.15 and 4.16.4?

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.

Is this issue about antenna select code? I want to be notified when antenna select code is fixed.

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.

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.

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.

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

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.

On linux 4.18.8, rtl8723be detects strong WiFi signals without ant_sel.

8723bs have the same weak signal problem.

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
        SSID: YOULING
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -83.00 dBm
        SSID: YOULING
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -83.00 dBm
        SSID: YOULING
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -85.00 dBm
        SSID: YOULING
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -85.00 dBm
        SSID: YOULING
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -87.00 dBm
        SSID: YOULING
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -88.00 dBm
        SSID: YOULING
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -90.00 dBm
        SSID: YOULING
# iw dev wlan0 scan | egrep "SSID|signal"
        signal: -90.00 dBm
        SSID: YOULING

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