Bug 1409631

I've been using this laptop for a long time, Wi-Fi worked great a few years ago, I do a clean install of Fedora every year or so.  Back when I did my clean install to Fedora 23, that broke the wifi and I had to use Larry Fingers driver that I found on this original bug report to fix it.  Now I've done a clean install of Fedora 25 and the wifi problem is still there, but unfortunately, Larry's driver no longer fixes the issue. :-(  The driver that I downloaded originally for Fedora 23 doesn't build for me on Fedora 25.  When I download again from git repo (updated version) it does build and install, but there is no change to Wi-Fi symptoms.

My lspci reports the same card as the original post has been installed inside of my HP ENVY 15-J017CL laptop.

01:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter [10ec:8179] (rev 01)
	Subsystem: Hewlett-Packard Company RTL8188EE mini-PCIe card [103c:197d]
	Kernel driver in use: rtl8188ee
	Kernel modules: rtl8188ee

All symptoms listed in the original post are correct for my situation.  I can connect, but small data transfers are unreliable and larger ones are extremely bad.



+++ This bug was initially created as a clone of Bug #1108801 +++

Description of problem:
Wireless connections established with 3.15 kernels is extremely unstable, slow, unreliable.
The connection is not "formally" lost, still, pinging any external server shows that more than 75% of the packets are lost. Using any web browser is extremely difficult.

Version-Release number of selected component (if applicable):
Currently testing with kernel-3.15.0-1.fc21.x86_64.
kernel-3.15.0-0.rc0.git5.1 is the last working kernel.

How reproducible:
Just browse or try to ping an external server

Steps to Reproduce:
1.Connect via wireless
2.Try to use the connection
3.Experience extremely slow network activity

Actual results:
Unbearable 

Expected results:
Good network activity

Additional info:
Here's the output of 'lspci -nnk | grep -iA6 net'

08:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter [10ec:8179] (rev 01)
        Subsystem: Hewlett-Packard Company Device [103c:197d]
        Kernel driver in use: rtl8188ee
        Kernel modules: rtl8188ee
09:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] (rev 08)
        Subsystem: Hewlett-Packard Company Device [103c:2164]
        Kernel driver in use: r8169

--- Additional comment from  on 2014-07-02 15:08:15 EDT ---

I've attempted to use 3.15.3-200.fc20.x86_64 for F20, I've the same issues. The connection is not unstable as in rawhide, but it's unbearable anyway.

Since F20 is going to receive 3.15 (currently it's an updates candidate), I'm considering moving this bug from rawhide to F20.

I've tested 3.16.0-0.rc3.git1.1 as well in rawhide, the wi-fi issue is still there.

--- Additional comment from Larry Finger on 2014-07-02 17:03:49 EDT ---

As you mention using git kernels, is it possible for you to bisect this issue?

--- Additional comment from  on 2014-07-02 18:20:33 EDT ---

Well, kernel-3.15.0-0.rc0.git5.1.fc21 is the last "good" one, as I've reported at comment #1

I've noticed this issue starting with kernel-3.15.0-0.rc0.git6.1.fc21 

I've tried to compare the drivers/net/wireless/rtlwifi/rtl8188ee folders in both the linux tarballs within the .src.rpm of  kernel-3.15.0-0.rc0.git5.1.fc21 and kernel-3.15.0-0.rc0.git6.1.fc21, but it seems the driver itself wasn't touch between these two git versions (as far as I can tell).

--- Additional comment from Larry Finger on 2014-07-02 19:30:00 EDT ---

I know there are no differences in rtl8188ee in that range.

You cannot do the bisection with a tarball - you need the git repo. As I cannot duplicate your result, there is nothing I can do unless you can point to a specific commit that causes the problem.

--- Additional comment from  on 2014-07-05 15:44:09 EDT ---

So, I did bisect the issue with the git repo. I just need to test the last test kernel, but I believe that the first bad commit is:

------------------------
commit 2a54eb5e1476426ee639bbfbe179b52342a0d82c
Author: Adam Lee <adam.lee>
Date:   Fri Mar 28 11:36:19 2014 +0800

    rtlwifi: rtl8188ee: enable MSI interrupts mode
    
    Some HP notebooks using this rtl8188ee hardware module can't get
    AP scan results with pin-based interrupts mode, enabling MSI interrupts
    mode could fix it.
    
    As RealTek's testing results, RTL8188EE works well with both MSI mode
    and pin-based mode fallback.
    
    Signed-off-by: Adam Lee <adam.lee>
    Signed-off-by: John W. Linville <linville>
-------------------

I was wrong in idenifying the regression window: the first bad kernel was kernel-3.15.0-0.rc0.git8.1.fc21, not kernel-3.15.0-0.rc0.git6.1.fc21 .
It took a while and ten kernels, hope it helps

--- Additional comment from  on 2014-07-05 16:22:00 EDT ---

I confirm that 2a54eb5e1476426ee639bbfbe179b52342a0d82c introduced this bug, and the previous commit 94010fa0dd07e8b904e7c6b6589f15573008ab15 was indeed revised ( http://patchwork.ozlabs.org/patch/342069/ )
Anyway, whilst bisecting, I've noticed something different.
It's true that "RTL8188EE
modules could not connect to any wireless network after the MSI mode was
enabled"; in fact, I've been completely unable to connect when I've encountered a bad kernel in my bisection tests.
"journalctl -f" whilst attempting to connect constantly showed

kernel: wlo1: deauthenticating from $BSSID by local choice (Reason: 3=DEAUTH_LEAVING)

and

kernel: wlo1: authentication with $BSSID  timed out

Still, I have to note that later kernels (with, I suppose, 94010fa0dd07e8b904e7c6b6589f15573008ab15 reverted: I tested 3.16.0-0.rc3.git1.1) can connect _but_ have serious issues (75% of packets lost, as I've mentioned in the bug report).

--- Additional comment from Larry Finger on 2014-07-05 21:08:31 EDT ---

Someone other than me or Realtek decided to use MSI interrupts for the RTL8188EE. It works for some motherboards, but obviously not yours. Other cases fail with pin-based interrupts and must use MSI. Commit 3513d00 made the selection be a module parameter and set the default to off. Thus, that problem is fixed in 3.16.

As to the loss of packets, I cannot duplicate your result. For the past 24 hours, I have been running my RTL8188EE using kernel 3.16-rc3 from wireless testing. It has had no problems, even when I used the link to do text editing over an ssh link. My ping results are

100 packets transmitted, 95 received, 5% packet loss, time 99122ms
rtt min/avg/max/mdev = 3.496/49.166/1003.763/109.197 ms, pipe 2

The 5% loss is higher than I would like, but the link is usable. The AP in question is a Netgear WNDR3400V2 with WPA2 encryption with the "iwlist scan" signal quality/strength given as "Quality=36/70  Signal level=-74 dBm". My antennas are placed in a less than optimal position.

After moving the antennas, I got "Quality=54/70  Signal level=-56 dBm". The ping results were

100 packets transmitted, 96 received, 4% packet loss, time 99126ms
rtt min/avg/max/mdev = 1.843/18.815/276.407/38.659 ms

The losses are still too high; however, the average response went from 49 to 18 ms. Obviously, -74 dBm indicated is near the minimum, and the performance is a lot better at -56 dBm.

--- Additional comment from  on 2014-07-07 09:18:02 EDT ---

I've rebuilt the latest rawhide kernel (available so far) on F20 
( 3.16.0-0.rc3.git3.1 )
and I'm glad to say that it works as expected.

Anyway, the latest F20 kernel available  in updates testing
(3.15.3-200.fc20)
as well as the first 3.16 kernel I tested (but in rawhide)
(3.16.0-0.rc3.git1.1)
did have this issue.

In F20, with 3.15.3-200.fc20, it's possible to use the wi-fi connection but the connection is extremely sluggish, and it gets stuck for a few seconds every now and then. With a connection quality of 40/70 the packet loss is ~75%. Only if I place the laptop within ~3 meters from the AP I get a connection quality of ~50/70, and I still experience a huge packet loss: the best results are

--- 8.8.8.8 ping statistics ---
123 packets transmitted, 85 received, 30% packet loss, time 122086ms
rtt min/avg/max/mdev = 27.596/1491.870/16800.730/3340.508 ms, pipe 17

I'm (slowly) trying to identify a reverse regression window in order to understand what to expect from future builds

--- Additional comment from Steve Alexander on 2014-07-25 15:27:16 EDT ---

I'm seeing the same problem with an HP Envy 15 (mobo1962) using
3.15.6-200.fc20.x86_64 .
Various tests show network throughput under 1Mbps.   Not excessive packet loss.


[root@mycena boot]# lshw -C network
  *-network               
       description: Wireless interface
       product: RTL8188EE Wireless Network Adapter
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:01:00.0
       logical name: wlo1
       version: 01
       serial: 34:23:87:27:33:c9
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=rtl8188ee driverversion=3.15.6-200.fc20.x86_64 firmware=N/A ip=192.168.42.153 latency=0 link=yes multicast=yes wireless=IEEE 802.11bgn
       resources: irq:48 ioport:5000(size=256) memory:b2600000-b2603fff
...
[root@mycena boot]# iwconfig wlo1
wlo1      IEEE 802.11bgn  ESSID:"darthbobo"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: 60:A4:4C:F1:51:00   
          Bit Rate=150 Mb/s   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr=2347 B   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=70/70  Signal level=-36 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:12   Missed beacon:0
[root@mycena boot]# ip -s link show dev wlo1
3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 34:23:87:27:33:c9 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    95552458   86788    0       0       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    9966507    62449    0       0       0       0

--- Additional comment from Steve Alexander on 2014-07-26 02:45:10 EDT ---

Kernel 3.16.0-0.rc6.git2.1.fc21.x86_64 also works as expected.

Note that "modprobe -r rtl8188ee;modprobe rtl8188ee" leaves the device in a state where it fails to successfully associate. However suspend/resume and hibernate/reboot work as expected.

--- Additional comment from Larry Finger on 2014-08-07 15:02:56 EDT ---

The latest version of the Realtek driver is at http://gitcub.com/lwfinger/rtlwifi_new.git. I will be merging that code into the kernel, but it may take a while. The code will build on any kernel version 3.0 or newer.

The usage is:
git clone http://gitcub.com/lwfinger/rtlwifi_new.git
cd rtlwifi_new
make
sudo modprobe -rv rtl8188ee
sudo make install
sudo modprobe -v rtl8188ee

--- Additional comment from Steve Alexander on 2014-08-10 17:40:03 EDT ---

To correct Larry Finger's notice.   It's "github" not "gitcub".
As he meant to say ....

The latest version of the Realtek driver is at http://github.com/lwfinger/rtlwifi_new.git. I will be merging that code into the kernel, but it may take a while. The code will build on any kernel version 3.0 or newer.

The usage is:
git clone http://github.com/lwfinger/rtlwifi_new.git
cd rtlwifi_new
make
sudo modprobe -rv rtl8188ee
sudo make install
sudo modprobe -v rtl8188ee

--- Additional comment from  on 2014-08-14 15:47:52 EDT ---

I've tested this new Realtek driver, it works fine so far.

--- Additional comment from Paul Sandel on 2014-08-21 09:09:52 EDT ---

I can confirm this bug and it's awesome destructive power. I've attempted to install the newest driver, per Steve Alexander's comment, however after make I recieve: 

make -C /lib/modules/3.15.10-200.fc20.x86_64/build M=/home/jamespaulsandel/Downloads/rtlwifi_new modules
make: *** /lib/modules/3.15.10-200.fc20.x86_64/build: No such file or directory.  Stop.
make: *** [all] Error 2

The path to build does exist, and build is a symbolic link. Any suggestions as to how to get around this?

--- Additional comment from Steve Alexander on 2014-08-22 03:02:47 EDT ---

Using Larry Finger's driver on 3.15.10-200.fc20.x86_64 I'm seeing more disassociations/disconnects than I did with a 3.16 koji kernel.  With previous 3.15... f20 drivers I was seeing difficulty associating, not disconnects.  I realize there may be a lot of factors involve.

Also, oddly some nearby WAPs do not appear in the NetworkManager list of WAPs.  These same WAPs do appear in the "iwlist scan" output.

--- Additional comment from Steve Alexander on 2014-08-22 03:36:59 EDT ---

It appears that the scan operation (as in iwlist scan) does not function well when the device is associated with a WAP, when using Larry Finger's driver.  Only catches the SSID broadcasts occasionally.

Manually dis-dissociating the driver allows scans to succeed normally.

--- Additional comment from Paul Sandel on 2014-08-22 10:59:25 EDT ---

With the help of Steve Alexander: 

You need ...
yum install kernel-devel-3.15.10-200.fc20.x86_64
you might also need,
yum groupinstall 'Development Tools'


I've installed this driver and it has solved my problems. I'm getting great connection and no visible problems.

--- Additional comment from Peter on 2014-08-28 15:45:14 EDT ---

Hi, everyone. Your efforts to resolve this are greatly appreciated however I have not been able to install the new driver.

When I run:

sudo yum modeprobe -v rtl8188ee

I receive the following:

modprobe: ERROR: could not insert 'rtl8188ee': Required key not available

Could you point me in the right direction please?

Thanks,

Peter

--- Additional comment from John Greene on 2014-08-29 09:11:56 EDT ---

Might be the easy to just build the entire kernel with your module and then just run it.  You have the tools already.  Give that a good.  Will at least fix the signing bugger.

--- Additional comment from Josh Boyer on 2014-08-29 09:14:30 EDT ---

Before you rebuild the entire kernel, you can just try running 'strip -g' on the .ko file.  That will remove any signature attached and unless you are booted in Secure Boot mode it should still load.

--- Additional comment from Peter on 2014-09-02 15:14:56 EDT ---

Thanks for the replies.

I've tried the 'strip -g' method but still get the same message.

Not tempted by a full kernel build as I've never had any luck with it in the past.

--- Additional comment from Justin W. Flory on 2014-09-04 17:25:46 EDT ---

For the record, I would just like to say that comment 12 resolved my issues! I was having issues with my NetworkManager dropping my WiFi connection, but after installing the drivers from GitHub, it seems my issue has cleared up.

--- Additional comment from Jaroslav Reznik on 2015-03-03 11:01:37 EST ---

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

--- Additional comment from Justin M. Forbes on 2015-10-20 15:27:38 EDT ---

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs.

Fedora 22 has now been rebased to 4.2.3-200.fc22.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23.

If you experience different issues, please open a new bug report for those.

--- Additional comment from Fedora Kernel Team on 2015-11-23 12:15:40 EST ---

*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.