Bug 998727 - Wireless very unreliable on most networks with ThinkPad T430 (RTL8188CE) [NEEDINFO]
Wireless very unreliable on most networks with ThinkPad T430 (RTL8188CE)
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: fedora-kernel-wireless-realtek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-19 18:39 EDT by Michael
Modified: 2014-12-10 10:02 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-10 10:02:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jforbes: needinfo?


Attachments (Terms of Use)
dmesg (241.76 KB, text/plain)
2013-08-20 19:46 EDT, Michael
no flags Details
lspci -nnvv (9.92 KB, text/plain)
2013-08-23 13:03 EDT, Michael
no flags Details
Patch to improve automatic gain control (71.10 KB, patch)
2013-09-26 15:50 EDT, Larry Finger
no flags Details | Diff
Patch to improve automatic gain control - revised (70.57 KB, patch)
2013-09-26 17:55 EDT, Larry Finger
no flags Details | Diff

  None (edit)
Description Michael 2013-08-19 18:39:48 EDT
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.
Comment 1 John Greene 2013-08-20 10:54:37 EDT
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.
Comment 2 Michael 2013-08-20 19:45:40 EDT
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.
Comment 3 Michael 2013-08-20 19:46:50 EDT
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.
Comment 4 John Greene 2013-08-23 10:46:29 EDT
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..
Comment 5 Michael 2013-08-23 13:03:32 EDT
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.
Comment 6 yybvsursmq 2013-09-07 02:56:16 EDT
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.
Comment 7 Josh Boyer 2013-09-18 16:39:09 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 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.
Comment 8 Michael 2013-09-21 12:34:58 EDT
Hi. Using this kernel and the problem still persists. No difference from before.
Comment 9 Larry Finger 2013-09-26 15:50:23 EDT
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.
Comment 10 Josh Boyer 2013-09-26 16:10:54 EDT
(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@gmail.com>
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@gmail.com>

Did you perhaps attach the wrong patch?
Comment 11 John Greene 2013-09-26 17:25:24 EDT
(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@gmail.com>
> 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@gmail.com>
> 
> Did you perhaps attach the wrong patch?

Well, I was confused too. Glad it's not just me..
Comment 12 Larry Finger 2013-09-26 17:54:32 EDT
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.
Comment 13 Larry Finger 2013-09-26 17:55:45 EDT
Created attachment 803613 [details]
Patch to improve automatic gain control - revised

New version without misleading commit message.
Comment 14 Justin M. Forbes 2014-01-03 17:12:14 EST
*********** 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.
Comment 15 Justin M. Forbes 2014-02-24 09:04:46 EST
*********** 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.
Comment 16 Joshua Roys 2014-02-25 19:44:58 EST
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)
Comment 17 Justin M. Forbes 2014-05-21 15:41:12 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 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.
Comment 18 Michael 2014-06-01 21:14:24 EDT
No change with latest kernel.
Comment 19 Justin M. Forbes 2014-11-13 11:04:21 EST
*********** 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 20 Justin M. Forbes 2014-12-10 10:02:58 EST
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.

Note You need to log in before you can comment on or make changes to this bug.