Unstable Wifi on laptop. RTL8723be How to fix it?

English Network/Internet
1

Hello everyone,

I installed OpenSUSE 42.1 in my Lenovo G-50 but like in others Linux distros the Wireless conection is very unstable. I works for the first five minutes but then it loses connection. I have to turn WIFI off and turn it on again or restart the PC.

In Ubuntu-based distros I solved it by reinstalling a new driver for the RTL8723be chip, but I don’t know how to do that in openSUSE or if it is the same problem and this would work.

This is the output for : sudo hwinfo --wlan

14: PCI 200.0: 0282 WLAN controller
[Created at pci.366]
Unique ID: y9sn.KuGs9FgPkuB
Parent ID: Z7uZ.S26Zq+XvnB0
SysFS ID: /devices/pci0000:00/0000:00:1c.3/0000:02:00.0
SysFS BusID: 0000:02:00.0
Hardware Class: network
Model: “Realtek RTL8723BE PCIe Wireless Network Adapter”
Vendor: pci 0x10ec “Realtek Semiconductor Co., Ltd.”
Device: pci 0xb723 “RTL8723BE PCIe Wireless Network Adapter”
SubVendor: pci 0x17aa “Lenovo”
SubDevice: pci 0xb736
Driver: “rtl8723be”
Driver Modules: “rtl8723be”
Device File: wlan0
Features: WLAN
I/O Ports: 0x3000-0x30ff (rw)
Memory Range: 0xc0400000-0xc0403fff (rw,non-prefetchable)
IRQ: 19 (no events)
HW Address: c0:3d:f6:35:5f:22
Link detected: yes
WLAN channels: 1 2 3 4 5 6 7 8 9 10 11 12 13
WLAN frequencies: 2.412 2.417 2.422 2.427 2.432 2.437 2.442 2.447 2.452 2.457 2.462 2.467 2.472
WLAN encryption modes: WEP40 WEP104 TKIP CCMP
WLAN authentication modes: open sharedkey wpa-psk wpa-eap
Module Alias: “pci:v000010ECd0000B723sv000017AAsd0000B736bc02sc80i00”
Driver Info #0:
Driver Status: rtl8723be is active
Driver Activation Cmd: “modprobe rtl8723be”
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #8 (PCI bridge)

I don’t know what to do. Any idea?

Thanks

2

You could try this.
https://forums.opensuse.org/showthread.php/517984-Unstable-realtek-WIFI-connection

3

Am Wed, 12 Oct 2016 13:16:02 GMT
schrieb hank se <hank_se@no-mx.forums.microfocus.com>:

> You could try this.
> http://tinyurl.com/jroyqdl
>
>

Hint, Hint:

http://software.opensuse.org/search?utf8=✓&q=rtlwifi_new&search_devel=false&search_unsupported=false&baseproject=openSUSE%3ALeap%3A42.1

http://download.opensuse.org/repositories/home:/Akoellh:/Kernelmodules/

One will need rtlwifi-new-kmp-FLAVOR matching your running kernel version and
flavor (pae, desktop, default, whatever, “uname -r” will tell you) and if the
respective firmware file is not included in kernel-firmware, there are also
matching firmware packages (noarch sub-folder).

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

4

Aha, that’s nice work. Good to know.

5

Am Wed, 12 Oct 2016 13:56:02 GMT
schrieb hank se <hank_se@no-mx.forums.microfocus.com>:

> Aha, that’s nice work. Good to know.
>

Important note:

Keep in mind that this does not guarantee that all those drivers will
work. It might be even possible that some of them are buggy or even buggier
than the ones in the mainline kernel.

The only thing I can guarantee is this:

The code is the latest (and greatest? see above) code from the source code repo
you linked in your first posting.

I use a branch with the latest (and greatest? see above) code for
bluetooth/wireless coexistence as some users reported that this is still an
issue despite the wireless driver now working better.

The main advantages over manually compiling and installing the drivers from
Larry Finger’s github repo are

a) easier to install

and as (or even more) important

b) easy to uninstall if they don’t work

In addition, I did not add all the firmware files as a dependecy (so they get
pulled in automagically by zypper) because of two main reasons.

  1. Some of them are already part of kernel-firmware (leading to conflicting
    packages)

  2. There are 14 kernel modules atm in one KMP-package, most of them need their
    unique firmware file(s) and there is a firmware package for every single one of
    them. it does not make sense to add all firmware packages as dependencies if
    the user only needs one of the drivers in the kmp package. The only other way
    to solve this would be to split up the kmp packages also, which is a PITA
    especially if there are some modules needed by all drivers (and there are at
    least 4 of them). Maybe I will try splitting up the kmp-package in the future,
    but not for now.

AK

Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)