Bug 1118390

Summary:	Wireless network disconnects a few minutes after log on, network manager claims connection still active. (RTL8723BE)
Product:	[Fedora] Fedora	Reporter:	johnps
Component:	kernel	Assignee:	fedora-kernel-wireless-realtek
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	dudaerich, gansalmon, itamar, jonathan, kernel-maint, larry.finger, lin.support, louis, madhu.chinakonda, markotikvic, mchehab, mtessun, peterdaugaardrasmussen, peter.rueckert, pviktori
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-04-28 18:23:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description johnps 2014-07-10 15:05:10 UTC

Description of problem: After logging on I can connect to my network however after a few minutes(usually just after a yum update stops downloading and start installing)  I cannot connect to the internet or my local network, while the network manager says the connection is still active. I cannot reconnect even if I turn the adapter off and on again in the network manager and this will occasionally cause the network manager to become stuck in either an off or on position. 


Version-Release number of selected component (if applicable): 3.15.3


How reproducible:


Steps to Reproduce:
1.Log on
2.wait a few minutes
3.attempt to access network

Actual results: network accessible


Expected results: network unreachable


Additional info:

Comment 1 Peter Rasmussen 2014-07-20 09:07:34 UTC

I just want to add that I have almost the exact same issue. I just bought a Lenovo thinkpad Z50 (RTL8723BE wirless card). However, my disconnection happens within the first 15-20 seconds. After a minute or so NetworkManager actually shows me as disconnected. I can browse a webpage or download a few packages before the connection is lost (but shows as accessible).

My kernel version is 3.15.5-200.fc20.x86_64.

I have tried using wicd aswell, same results.

Running iwconfig tells me Power Management:off.

I am not sure if this is the exact same issue, let me know if I should submit my own bug.

Comment 2 johnps 2014-07-20 11:14:58 UTC

I think that's the same issue. I've noticed variety in how long I stay connected, I definitely can't always update now. If I leave it long enough it does seem to reconnect if only for a short while. I think the driver is just a bit dodgy, when I installed it myself from github onto 3.14 the driver didn't compile due to a typo and was also prone to disconnecting.

Comment 3 Aniruddh Singh 2014-07-25 03:59:55 UTC

I am facing same problem on Lenovo Flex 2, which has the same card RTL8723be, frequently see connection lost message and it reconnects again, here is what I can see in log

Jul 25 09:04:26 localhost.localdomain kernel: wlp2s0: Connection to AP 00:00:00:00:00:00 lost
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211: Calling CRDA to update world regulatory domain
Jul 25 09:04:26 localhost.localdomain gnome-session[1238]: Gjs-Message: JS LOG: An active wireless connection, in infrastructure mode, involves no access point?
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211: World regulatory domain updated:
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:  DFS Master region: unset
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211: Calling CRDA for country: IN
Jul 25 09:04:26 localhost.localdomain NetworkManager[1034]: <info> (wlp2s0): supplicant interface state: completed -> disconnected
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211: Regulatory domain changed to country: IN
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:  DFS Master region: unset
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2000 mBm), (0 s)
Jul 25 09:04:26 localhost.localdomain kernel: cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
Jul 25 09:04:26 localhost.localdomain NetworkManager[1034]: <info> (wlp2s0): supplicant interface state: disconnected -> scanning
Jul 25 09:04:27 localhost.localdomain kernel: wlp2s0: authenticate with 98:fc:11:40:95:aa
Jul 25 09:04:27 localhost.localdomain kernel: wlp2s0: send auth to 98:fc:11:40:95:aa (try 1/3)
Jul 25 09:04:27 localhost.localdomain NetworkManager[1034]: <info> (wlp2s0): supplicant interface state: scanning -> authenticating
Jul 25 09:04:27 localhost.localdomain kernel: wlp2s0: authenticated
Jul 25 09:04:27 localhost.localdomain kernel: wlp2s0: associate with 98:fc:11:40:95:aa (try 1/3)
Jul 25 09:04:27 localhost.localdomain kernel: wlp2s0: RX AssocResp from 98:fc:11:40:95:aa (capab=0x411 status=0 aid=6)
Jul 25 09:04:27 localhost.localdomain kernel: wlp2s0: associated
Jul 25 09:04:27 localhost.localdomain NetworkManager[1034]: <info> (wlp2s0): supplicant interface state: authenticating -> associated
Jul 25 09:04:27 localhost.localdomain NetworkManager[1034]: <info> (wlp2s0): supplicant interface state: associated -> 4-way handshake
Jul 25 09:04:27 localhost.localdomain NetworkManager[1034]: <info> (wlp2s0): supplicant interface state: 4-way handshake -> completed
Jul 25 09:04:27 localhost.localdomain NetworkManager[1034]: <info> (wlp2s0): roamed from BSSID (none) ((none)) to 98:FC:11:40:95:AA

Comment 4 Aniruddh Singh 2014-07-25 04:00:24 UTC

Anyone looking into this?

Comment 5 Aniruddh Singh 2014-07-26 05:24:52 UTC

Just to update that I am using following kernel

3.15.6-200.fc20.i686+PAE

Comment 6 Peter Rasmussen 2014-07-30 10:04:36 UTC

Has anyone found a workaround for this?

I am still having this issue.

Comment 7 Aniruddh Singh 2014-08-02 16:30:49 UTC

No solution yet

Comment 8 peter.rueckert 2014-08-06 09:14:23 UTC

Same problem on HP Pavilion 17 with kernel 3.15.7-200.fc20.x86_64
Sometimes extended use of wireless network is possible, sometimes it "hangs" after a few minutes.
In rtl8723be msi is set to false, with msi true (in 3.15.6) wireless network was completely unusable. Following other posts I've set the following kernel parameters in grub commandline: rtl8723be.fwlps=0 rtl8723be.swlps=0

Comment 9 Larry Finger 2014-08-06 13:52:22 UTC

You should learn how to set options in .etc.modprobe.d/. It is a lot easier than changing the grub command line.

The latest versions of all the Realtek PCI drivers can be found at http://github.com/lwfinger/rtlwifi_new.git. Those will build with any kernel 3.0 r later.

Comment 10 Louis van Dyk 2014-08-14 13:31:46 UTC

I am having the same problem on a Lenovo E540.  I was happily using the wireless in kernel 3.14.x by compiling and adding in the modules from rtl8723be-master that was given to me by someone via Bugzilla.  But since 3.15, when it's supposed to have been built in, it has not been working.  

I turn on the wireless, and start pinging a host.  After 15 pings, the traffic stopped.  The wireless appears to be connected, but the signal almost disappears.

I am on kernel-3.15.8-200.fc20.x86_64

[root@lenovo ~]# lsmod | grep rtl
rtl8723be              85031  0 
btcoexist              50180  1 rtl8723be
rtl8723_common         21560  1 rtl8723be
rtl_pci                26490  1 rtl8723be
rtlwifi                61805  2 rtl_pci,rtl8723be
mac80211              608109  3 rtl_pci,rtlwifi,rtl8723be
cfg80211              493377  2 mac80211,rtlwifi

Comment 11 Larry Finger 2014-08-14 14:38:03 UTC

Use the code in comment 9. It is the latest Realtek version.

Comment 12 Louis van Dyk 2014-08-14 14:55:54 UTC

** WORKAROUND **

Go to https://github.com/lwfinger/rtlwifi_new and click the Download ZIP button, or else 

wget https://github.com/lwfinger/rtlwifi_new/archive/master.zip

cd rtlwifi_new-master

make install

modprobe -v rtl8723be    (or reboot)

It has been working perfectly since I have done that. I am on kernel 3.15.8-200.

Comment 13 Larry Finger 2014-08-14 15:34:00 UTC

It is better for you to get the code using 'git clone http://github.com/lwfinger/rtlwifi_new.git'.

If you download the zip, you will need to re-download *all* of it every time I make a change. With the git repo, all you need if 'git pull' to get only the changes.

Comment 14 peter.rueckert 2014-08-15 20:50:04 UTC

Using the latest version (see comments 11-13) seems to work for me as well (kernel 3.15.8-200)

Comment 15 Peter Rasmussen 2014-08-16 17:16:42 UTC

The fix above worked for me (kernel 3.15.9-200). I have hereby been browsing for 20 minutes without a disconnect.

Thank you so much!

Comment 16 Martin Tessun 2014-10-25 19:06:15 UTC

Hi,

just some feedback on the newest driver (from Larrys newest git repo rtlwifi_new.git):

1. It does not disconnect anymore (so a big improvement in relation to the "old" driver from kernel-3.16.6-200.fc20.x86_64
2. It still is somewhat flaky (losing pings, ping RTT going up to 10 seconds)

The logs are more or less empty (besides the initialisation stuff):
...
Oct 25 20:47:49 xxx NetworkManager[929]: <info> Activation (wlp2s0) Stage 5 of 5 (IPv6 Commit) scheduled...
Oct 25 20:47:49 xxx NetworkManager[929]: <info> Activation (wlp2s0) Stage 5 of 5 (IPv6 Commit) started...
Oct 25 20:47:49 xxx NetworkManager[929]: <info> Activation (wlp2s0) Stage 5 of 5 (IPv6 Commit) complete.
Oct 25 20:47:49 xxx dbus[863]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedes
Oct 25 20:47:49 xxx dbus-daemon[863]: dbus[863]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit
Oct 25 20:47:49 xxx NetworkManager[929]: <info> (wlp2s0): DHCPv6 client pid 5592 exited with status 0

ping looks like this:
PING gateway.example.com (xxx.xxx.xxx.xxx) 56(84) bytes of data.
64 bytes from gateway.example.com (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=64 time=8.30 ms
64 bytes from gateway.example.com (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=64 time=1012 ms
64 bytes from gateway.example.com (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=64 time=12.1 ms
64 bytes from gateway.example.com (xxx.xxx.xxx.xxx): icmp_seq=6 ttl=64 time=1012 ms
64 bytes from gateway.example.com (xxx.xxx.xxx.xxx): icmp_seq=7 ttl=64 time=12.9 ms
64 bytes from gateway.example.com (xxx.xxx.xxx.xxx): icmp_seq=10 ttl=64 time=1013 ms
64 bytes from gateway.example.com (xxx.xxx.xxx.xxx): icmp_seq=11 ttl=64 time=13.7 ms
...
--- gateway.example.com ping statistics ---
51 packets transmitted, 38 received, 25% packet loss, time 50049ms
rtt min/avg/max/mdev = 7.074/379.895/2013.418/625.948 ms, pipe 3


I have no additional options set:

[dana@schrotti bugzilla]$ modinfo rtl8723be
filename:       /lib/modules/3.16.6-200.fc20.x86_64/kernel/drivers/net/wireless/rtlwifi/rtl8723be/rtl8723be.ko
firmware:       rtlwifi/rtl8723befw.bin
description:    Realtek 8723BE 802.11n PCI wireless
license:        GPL
author:         Realtek WlanFAE	<wlanfae>
author:         PageHe	<page_he.cn>
alias:          pci:v000010ECd0000B723sv*sd*bc*sc*i*
depends:        rtlwifi,rtl_pci,btcoexist,mac80211
vermagic:       3.16.6-200.fc20.x86_64 SMP mod_unload 
signer:         Systemtap module signing key
sig_key:        A2:7F:30:AC:74:6A:D7:DE:66:84:34:51:E5:51:3C:20:56:79:C5:E6
sig_hashalgo:   sha512
parm:           swlps:bool
parm:           swenc:using hardware crypto (default 0 [hardware])
 (bool)
parm:           ips:using no link power save (default 1 is open)
 (bool)
parm:           fwlps:using linked fw control power save (default 1 is open)
 (bool)
parm:           msi:Set to 1 to use MSI interrupts mode (default 0)

parm:           debug:Set debug level (0-5) (default 0) (int)
parm:           disable_watchdog:Set to 1 to disable the watchdog (default 0)
 (bool)

Hardware information:
lspci -k
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
	Subsystem: Lenovo Device b736
	Kernel driver in use: rtl8723be
	Kernel modules: rtl8723be

lspci -n:
02:00.0 0280: 10ec:b723

Please let me know if you need any further tests or information. I am happy to help debugging/solving this issue.

Comment 17 Justin M. Forbes 2014-11-13 16:01:59 UTC

*********** 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 20 kernel bugs.

Fedora 20 has now been rebased to 3.17.2-200.fc20.  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 21, and are still experiencing this issue, please change the version to Fedora 21.

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

Comment 18 Martin Tessun 2014-11-14 11:59:04 UTC

The issue does still exist on my Fedora-20 with the newest kernel (3.17.2-200.fc20).

It does no longer happen that often, and if it happens it does not show anything in the logs, but pings, etc. do not work any longer.

Restarting the Network doesn't help, unloading and reloading the module sometimes lead to a system freeze.

So yes, the issue is still there with the newest kernel.

Comment 19 Erich Duda 2015-01-28 18:32:15 UTC

I have similar issue on Fedora 21 with kernel 3.18.3-201.fc21.x86_64. I have notebook Lenovo E540 with wireless card RTL8723BE.

The connection is lost approximately each 30 minutes and after several seconds it is back on.

My log:

jan 28 19:26:00 localhost.localdomain kernel: wlp5s0: deauthenticated from e8:40:f2:7e:86:42 (Reason: 16=GROUP_KEY_HANDSHAKE_TIMEOUT)
jan 28 19:26:00 localhost.localdomain NetworkManager[926]: <warn>  Connection disconnected (reason 16)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211: Calling CRDA to update world regulatory domain
jan 28 19:26:00 localhost.localdomain NetworkManager[926]: <info>  (wlp5s0): supplicant interface state: completed -> disconnected
jan 28 19:26:00 localhost.localdomain kernel: cfg80211: World regulatory domain updated:
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:  DFS Master region: unset
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211: Calling CRDA for country: SK
jan 28 19:26:00 localhost.localdomain kernel: cfg80211: Regulatory domain changed to country: SK
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:  DFS Master region: ETSI
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (5490000 KHz - 5710000 KHz @ 160000 KHz), (N/A, 2700 mBm), (0 s)
jan 28 19:26:00 localhost.localdomain kernel: cfg80211:   (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
jan 28 19:26:00 localhost.localdomain NetworkManager[926]: <info>  (wlp5s0): supplicant interface state: disconnected -> scanning
jan 28 19:26:01 localhost.localdomain kernel: wlp5s0: authenticate with e8:40:f2:7e:86:42
jan 28 19:26:01 localhost.localdomain kernel: wlp5s0: send auth to e8:40:f2:7e:86:42 (try 1/3)
jan 28 19:26:01 localhost.localdomain NetworkManager[926]: <info>  (wlp5s0): supplicant interface state: scanning -> authenticating
jan 28 19:26:01 localhost.localdomain kernel: wlp5s0: authenticated
jan 28 19:26:01 localhost.localdomain kernel: wlp5s0: associate with e8:40:f2:7e:86:42 (try 1/3)
jan 28 19:26:01 localhost.localdomain kernel: wlp5s0: RX AssocResp from e8:40:f2:7e:86:42 (capab=0x411 status=0 aid=1)
jan 28 19:26:01 localhost.localdomain kernel: wlp5s0: associated
jan 28 19:26:01 localhost.localdomain NetworkManager[926]: <info>  (wlp5s0): supplicant interface state: authenticating -> associating
jan 28 19:26:01 localhost.localdomain NetworkManager[926]: <info>  (wlp5s0): supplicant interface state: associating -> associated
jan 28 19:26:01 localhost.localdomain NetworkManager[926]: <info>  (wlp5s0): supplicant interface state: associated -> 4-way handshake
jan 28 19:26:01 localhost.localdomain NetworkManager[926]: <info>  (wlp5s0): supplicant interface state: 4-way handshake -> completed

Comment 20 Larry Finger 2015-01-28 19:29:10 UTC

As the log says, you are getting a group key timeout. If the interval is exactly 30 minutes, that is likely the rekey period for the TKIP part of the WPA encryption. That interval seems a little short. If you have control of the AP, it that a parameter you can change? Most use 3600 sec.

Are you using WPA or WPA2?

Comment 21 Erich Duda 2015-01-28 19:57:24 UTC

Unfortunately I don't have control of the AP, but when I'll be at home (at my parents) I'll try it.

I studied the log more precisely to find the interval of loosing the connection and it is not exactly 30 minutes. The disconnections happened in 16:44:00, 17:50:00, 17:56:00, 18:06:00, 18:52:03, 19:18:00, 19:26:00, 20:46:00, 20:52:00.

Comment 22 Erich Duda 2015-01-28 20:01:45 UTC

And I forgot, I am using WPA2.

Comment 23 Erich Duda 2015-01-29 21:55:05 UTC

I tried to return back to linux kernel 3.17.8-300 and the problem with loosing connection is gone.

Note:
When I lost connection under kernel 3.18.3-201, so the GROUP_KEY_HANDSHAKE_TIMEOUT error doesn't appear always. Sometimes I lost connection and there wasn't any record in log about it.

Comment 24 Larry Finger 2015-01-30 02:01:19 UTC

The driver in 3.18 is a new version that is a lot different than 3.17.

Try loading the driver with the "ips=0" option in 3.18.3. That helps some users. It appears to be an incompatibility with certain APs.

Comment 25 Erich Duda 2015-02-01 15:02:16 UTC

I tried it but the problem persists.

Comment 26 Fedora Kernel Team 2015-02-24 16:22:20 UTC

*********** 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 20 kernel bugs.

Fedora 20 has now been rebased to 3.18.7-100.fc20.  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 21, and are still experiencing this issue, please change the version to Fedora 21.

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

Comment 27 Fedora Kernel Team 2015-04-28 18:23:23 UTC

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

Comment 28 Marko Tikvic 2015-10-10 12:15:00 UTC

I've had the exact issue with with RTL8723BE card. The problem is in default power save settings. Honestly this is a known bug for quite some time and I can't believe nobody has addressed it properly. This is what solved it for me:

1. Open terminal
2. Locate file "/etc/modprobe.d/rtl8723be.conf"
3a. if the file doesn't exist, crate it with command "sudo touch rtl8723.conf"
3b. enter command "sudo vi /etc/modprobe.d/rtl8723be.conf"
4. add line "options rtl8723be fwlps=0 swlps=0"
5. save and reboot

Hope this helps.