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:
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.
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.
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
Anyone looking into this?
Just to update that I am using following kernel 3.15.6-200.fc20.i686+PAE
Has anyone found a workaround for this? I am still having this issue.
No solution yet
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
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.
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
Use the code in comment 9. It is the latest Realtek version.
** 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.
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.
Using the latest version (see comments 11-13) seems to work for me as well (kernel 3.15.8-200)
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!
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.
*********** 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.
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.
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
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?
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.
And I forgot, I am using WPA2.
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.
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.
I tried it but the problem persists.
*********** 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.
*********** 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.
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.