Apologies if the kernel is the wrong package- I'm unsure which component to select. Description of problem: On most networks the wireless is very flaky. Frequent disconnects, connection failures, timeouts, and very slow download speeds (measured in bytes). There's no pattern to whether or not the connections will work. Sometimes I can connect and use wireless for an hour, other times I cannot even connect to a network. Turning the wifi off and on again briefly fixes the connection. No such issues when using Windows or other devices. Version-Release number of selected component (if applicable): Unsure. How reproducible: Any time I attempt to connect to a wireless network. Connection died multiple times while creating this bug report. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: My wireless device is "Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)". According to Google searches, instability with this hardware is common.
Unfortunately, your info is correct on older kernels. Can you: Later kernels (3.9+) improve this device in my testing. Can you upload a dmesg output (dmesg > dmesg.txt) Also, check your networkmanager, and wpa_supplicant packages are current.
Hi. I've experienced this problem on 3.8, 3.9, and 3.10 kernels. I currently use Fedora 19 with 3.9.11 (can't use 3.10.x due to a separate issue, but the problem is unsolved there too). I'm using the latest versions of networkmanager and wpa_supplicant that are available on Fedora 19.
Created attachment 788671 [details] dmesg Haven't used wireless too much today. Wireless is also behaving properly at the moment (happens sometimes, but rarely), so not sure how much useful information this will give.
Thanks for the log. It does seem odd to be vascillating between world and CA domains so frequently. Might check the crda package as well for an update. can you add the output of: lspci -nnvv Thanks..
Created attachment 789673 [details] lspci -nnvv crda is also fully up to date (crda-1.1.3_2013.02.13-2.fc19.x86_64). I tend to check for updates daily.
I am also having this problem with connection cutting out. I just noticed, though, that right now I have a long download going and so far (at least 2 hours) it has not dumped the connection and the browser works as well. As long as it is with continuous activity, the connection stays. This might be some sort of wakeup problem? Hope this helps you find this nasty bug.
*********** 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 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Hi. Using this kernel and the problem still persists. No difference from before.
Created attachment 803559 [details] Patch to improve automatic gain control The current code for rtl8192ce and rtl8192cu could fail to control the RX and TX gain with some setups. Unfortunately, my configuration does not have the problem. This patch improves the situation quite a bit. Please test. The patch will not be sent to the kernel for some time as it needs more testing, and there is still room for improvement.
(In reply to Larry Finger from comment #9) > Created attachment 803559 [details] > Patch to improve automatic gain control > > The current code for rtl8192ce and rtl8192cu could fail to control the RX > and TX gain with some setups. Unfortunately, my configuration does not have > the problem. > > This patch improves the situation quite a bit. Please test. The patch will > not be sent to the kernel for some time as it needs more testing, and there > is still room for improvement. I could be confused, but this attachment is: commit 6c7196d0119f0a19ba76a9844ed1590380c687a8 Author: Catalin Iacob <iacobcatalin> Date: Sun Sep 22 11:06:26 2013 +0200 rtlwifi: remove duplicate declarations and macros in headers This patch brings no functional change. There are still duplicate macros across the rtlwifi directory, for example IQK_DELAY_TIME is defined multiple times, sometimes with different values, this patch only removes duplicates within the same header file. Signed-off-by: Catalin Iacob <iacobcatalin> Did you perhaps attach the wrong patch?
(In reply to Josh Boyer from comment #10) > (In reply to Larry Finger from comment #9) > > Created attachment 803559 [details] > > Patch to improve automatic gain control > > > > The current code for rtl8192ce and rtl8192cu could fail to control the RX > > and TX gain with some setups. Unfortunately, my configuration does not have > > the problem. > > > > This patch improves the situation quite a bit. Please test. The patch will > > not be sent to the kernel for some time as it needs more testing, and there > > is still room for improvement. > > I could be confused, but this attachment is: > > commit 6c7196d0119f0a19ba76a9844ed1590380c687a8 > Author: Catalin Iacob <iacobcatalin> > Date: Sun Sep 22 11:06:26 2013 +0200 > > rtlwifi: remove duplicate declarations and macros in headers > > This patch brings no functional change. > > There are still duplicate macros across the rtlwifi directory, for > example > IQK_DELAY_TIME is defined multiple times, sometimes with different > values, > this patch only removes duplicates within the same header file. > > Signed-off-by: Catalin Iacob <iacobcatalin> > > Did you perhaps attach the wrong patch? Well, I was confused too. Glad it's not just me..
The patch is OK. In my working tree, I had already applied that commit by Catalin Iacob, thus it had to be included for any changes. I forgot to remove his commit message, but there is a lot more material in that patch than in his. To avoid confusion, I'll add a new attachment without that message.
Created attachment 803613 [details] Patch to improve automatic gain control - revised New version without misleading commit message.
*********** 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 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. 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 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
*********** 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.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
I've tested with 3.13.4-100.fc19.x86_64 both without and with "ips=0 fwlps=0" with the same terrible results. My card info: 01:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01) Immediately after connecting I started a ping: 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=1 ttl=64 time=1.23 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=2 ttl=64 time=1.37 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=3 ttl=64 time=2.30 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=4 ttl=64 time=17.9 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=5 ttl=64 time=1.73 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=7 ttl=64 time=1.23 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=11 ttl=64 time=1849 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=12 ttl=64 time=849 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=13 ttl=64 time=1.04 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=14 ttl=64 time=8.05 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=15 ttl=64 time=16.6 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=17 ttl=64 time=105 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=18 ttl=64 time=8.37 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=19 ttl=64 time=6.78 ms 64 bytes from WDR4300.lan (192.168.1.1): icmp_seq=20 ttl=64 time=10.8 ms I was disconnected a few times: Feb 25 19:23:41 jericho.lan kernel: wlo1: deauthenticated from 64:70:02:77:ec:4d (Reason: 2) Feb 25 19:23:41 jericho.lan NetworkManager[583]: <warn> Connection disconnected (reason 2) [...] Feb 25 19:23:42 jericho.lan NetworkManager[583]: <info> (wlo1): supplicant interface state: associated -> 4-way handshake Feb 25 19:23:46 jericho.lan kernel: wlo1: deauthenticated from 64:70:02:77:ec:4d (Reason: 2) Feb 25 19:23:46 jericho.lan kernel: cfg80211: Calling CRDA to update world regulatory domain Feb 25 19:23:46 jericho.lan NetworkManager[583]: <warn> Connection disconnected (reason 2) The router shows nothing unusual: Tue Feb 25 19:20:00 2014 daemon.info hostapd: wlan0: STA ac:81:12:ad:56:89 IEEE 802.11: authenticated Tue Feb 25 19:20:00 2014 daemon.info hostapd: wlan0: STA ac:81:12:ad:56:89 IEEE 802.11: associated (aid 2) Tue Feb 25 19:20:00 2014 daemon.info hostapd: wlan0: STA ac:81:12:ad:56:89 WPA: pairwise key handshake completed (RSN) Tue Feb 25 19:23:42 2014 daemon.info hostapd: wlan0: STA ac:81:12:ad:56:89 IEEE 802.11: authenticated Tue Feb 25 19:23:42 2014 daemon.info hostapd: wlan0: STA ac:81:12:ad:56:89 IEEE 802.11: associated (aid 2) Tue Feb 25 19:23:49 2014 daemon.info hostapd: wlan0: STA ac:81:12:ad:56:89 IEEE 802.11: authenticated Tue Feb 25 19:23:49 2014 daemon.info hostapd: wlan0: STA ac:81:12:ad:56:89 IEEE 802.11: associated (aid 2) Tue Feb 25 19:23:49 2014 daemon.info hostapd: wlan0: STA ac:81:12:ad:56:89 WPA: pairwise key handshake completed (RSN) This is an incredibly frustrating issue. I've been using a USB dongle for a while now to have working wifi. These issues really seemed to get worse around the 3.10 kernel upgrade IIRC which seems to be backed up by https://bugzilla.kernel.org/show_bug.cgi?id=60713 . For reference, the USB device gets perfect ping results. This is with me sitting in the same location, about 20 feet of empty space to the router. 20 packets transmitted, 20 received, 0% packet loss, time 19032ms rtt min/avg/max/mdev = 0.911/4.358/21.133/5.618 ms And the router has this info for the USB device: -46 dBm -95 dBm (Signal/Noise)
*********** 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.14.4-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 experience different issues, please open a new bug report for those.
No change with latest kernel.
*********** 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.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 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.