Bug 998924 - horrible connectivity on wifi - rtl8188cus
Summary: horrible connectivity on wifi - rtl8188cus
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: fedora-kernel-wireless-realtek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-20 11:02 UTC by Mohammed Arafa
Modified: 2015-02-17 16:50 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 16:50:40 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg wifi (251.79 KB, text/plain)
2013-08-21 11:32 UTC, Mohammed Arafa
no flags Details
messages for wifi (2.75 MB, text/plain)
2013-08-21 11:33 UTC, Mohammed Arafa
no flags Details
dmesg output (84.50 KB, text/plain)
2013-09-29 14:55 UTC, John Reiser
no flags Details
Patch to improve automatic gain control (70.57 KB, patch)
2013-09-29 15:06 UTC, Larry Finger
no flags Details | Diff
dmesg output for master_patch_rtlwifi.patch (98.66 KB, text/plain)
2013-09-29 23:31 UTC, John Reiser
no flags Details
dmesg output: warning trace, no connectivity via wifi (73.10 KB, text/plain)
2014-01-03 23:29 UTC, John Reiser
no flags Details
dmesg output: warning trace, no connectivity via wifi (73.09 KB, text/plain)
2014-01-22 22:53 UTC, John Reiser
no flags Details

Description Mohammed Arafa 2013-08-20 11:02:39 UTC
Description of problem:

what i see is network manager asking me for the SAVED secret key every few minutes. i know it is saved because i can see it in the keys.wifi file in /etc/sysconfig/network-scripts PLUS i can see it when i check the box that says show the secret key

then i looked in /var/log/messages and apparently the wifi is being reconnected every 10 to 15 seconds.

this is my device : Bus 001 Device 003: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

this is a desktop that i have cut the cable from. i would really appreciate some help here.

thanks

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 John Greene 2013-08-20 14:46:28 UTC
can you add some info here?
Try to do the connection, let the problem occur and then:

dmesg > dmesg.txt 
And kindly upload the file here.

Is your problem with a specific location or not?

Comment 2 Mohammed Arafa 2013-08-21 11:29:02 UTC
hello john

i got some good news and some bad news:
i reseated the usb wifi dongle and i no longer get "disconnected". network manager does ask me for the key (like right now the dialog box is open - really!) but i am connected.

irc tells me i disconnected 4 times since the last reboot :
system boot  2013-08-20 18:21 (EST)
times of disconnects
11.30pm
12:06am
1.40am
2:00am
2.10am

i will be attaching the messages and the dmesg log. apologies if it is too big

location: this is a desktop with a usb wifi dongle

Comment 3 Mohammed Arafa 2013-08-21 11:32:55 UTC
Created attachment 788822 [details]
dmesg wifi

dmesg wifi

Comment 4 Mohammed Arafa 2013-08-21 11:33:46 UTC
Created attachment 788823 [details]
messages for wifi

messages for wifi

Comment 5 Mohammed Arafa 2013-08-23 00:10:10 UTC
this is frustrating. the desktop is only 5 feet away from the access point and it has horrible speeds

Comment 6 John Greene 2013-08-23 14:00:19 UTC
Thanks for the info.  
I feel you: the adapter is having a hard time with connections, getting there and then dropping off, but interestingly doesn't say why.

The logs show that: but I don't see a kernel version.  What version are you running?  (uname -a).  Please post that for me,

If you are below 3.9, have you tried something later?  I know some fixes in 3.9 something seemed to make these USB adapters much happier.

Comment 7 Mohammed Arafa 2013-08-24 11:13:09 UTC
john 
i update automatically everyday ...and reboot within days or if i notice a kernel update occurred i close everything and reboot. so that makes it 3.10.x coz if i remember correctly 2 kernel updates occurred since this adventure began

as for connectivity i dug out an old old dlink usb wifi dongle and while it has hardware problems (confirmed by google) it is not as major as disconnecting the desktop from the network nor does it fill up the logs.

so any time you need me to do some testing, let me know, i will switch the dongles around for a bit to test and get the results back to you

thank you for your patience and help

Comment 8 John Greene 2013-08-27 15:35:16 UTC
Mohammed,

Great that you stay up to date and are so willing to test.

  But I'd like an exact version so I can look at the right source for you..Can you please post the uname -a output please?  Thanks.

Comment 9 Mohammed Arafa 2013-08-28 11:13:19 UTC
kernel-3.10.7-200.fc19.x86_64

Comment 10 Josh Boyer 2013-09-18 20:23:19 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 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 11 John Reiser 2013-09-29 14:54:47 UTC
[See also bug 998727]

I see the same problem [I get no connect at all in Fedora 19; but works fine in Windows7]:
  kernel-3.11.1-200.fc19.x86_64
  crda-1.1.3_2013.02.13-2.fc19.x86_64
  NetworkManager-0.9.8.2-9.git20130709.fc19.x86_64
and hardware:
  02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)

02:00.0 0280: 10ec:8178 (rev 01)
        Subsystem: 10ec:8178
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: I/O ports at d000 [size=256]
        Region 2: Memory at fe900000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: rtl8192ce

I will attach dmesg output with a kernel warning traceback for an explicit connect attempt, plus a few radio adjustments.

Comment 12 John Reiser 2013-09-29 14:55:42 UTC
Created attachment 804725 [details]
dmesg output

Comment 13 Larry Finger 2013-09-29 15:06:43 UTC
Created attachment 804726 [details]
Patch to improve automatic gain control

This patch improves the automatic gain control. Please test to see if it helps your problem.

Comment 14 John Reiser 2013-09-29 23:31:33 UTC
Created attachment 804830 [details]
dmesg output for master_patch_rtlwifi.patch

After modifying kernel.spec with the patch, building, "yum install kernel-3.11.1-200.jreiser.fc19.x86_64.rpm", and booting, then I still get no connectivity using rtl8188ce.  This attachment contains what dmesg says.

The rpmbuild output (grep rtlwifi.patch) shows:
-----
+ ApplyPatch master_patch_rtlwifi.patch
+ local patch=master_patch_rtlwifi.patch
+ '[' '!' -f /home/jreiser/rpmbuild/SOURCES/master_patch_rtlwifi.patch ']'
Patch27000: master_patch_rtlwifi.patch
-----
so I think that what I booted actually contains the patch, but I was disappointed that the patch numbers don't seem to mean anything anymore.  I would have liked a warning that 20GB of disk space would be consumed by "rpmbuild -ba"; it didn't used to be that much.  And if several "rpmbuild --without ..." flags would work OK but still give the needed info, then that would be nice to know, too.
Anyway, I hope that the dmesg output provides some clues.

Comment 15 Justin M. Forbes 2014-01-03 22:04:37 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 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 16 John Reiser 2014-01-03 23:29:52 UTC
Created attachment 845129 [details]
dmesg output: warning trace, no connectivity via wifi

(In reply to Justin M. Forbes from comment #15)
I still see the same problem: the card's antennas are 0.5m (19 inches) from the router's antennas; wifi works from handheld devices; NetworkManager Settings shows "checked", locked, strongest signal; but no data flows: "ping <the router's numerical IP4>" shows no packets getting through.

Note the dmesg traceback beginning around:
[   79.393402] WARNING: CPU: 2 PID: 456 at net/mac80211/rate.c:518 ieee80211_get_tx_rates+0x273/0x7f0 [mac80211]()

The card is:
05:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
05:00.0 0280: 10ec:8178 (rev 01)

The kernel is:
Linux f19s.local 3.12.6-200.fc19.x86_64 #1 SMP Mon Dec 23 16:33:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Comment 17 John Reiser 2014-01-03 23:52:25 UTC
The router lists the card's MAC address in its table of active connections.  Signal: -29;  Noise: -73;  SNR: 49;  Signal Quality: 86% to 92%.

Comment 18 Colonel Panic 2014-01-22 07:59:25 UTC
I just got one of these dongles myself (bought to help get around problems with another Realtek device built into my laptop), wouldn't have bought it if I knew it was a Realtek chip since every WiFi problem I've ever had in Linux has to do with them.

My device can connect to the router, even at distance which is good. But the reliability of the connection is terrible. Haven't noticed disconnects, but speed greatly fluctuates between about 10MBps and zero. dmesg shows nothing useful.

Running 3.12 kernel, so of course Realtek official drivers don't work :(

Comment 19 John Greene 2014-01-22 16:32:13 UTC
(In reply to John Reiser from comment #16)
> Created attachment 845129 [details]
> dmesg output: warning trace, no connectivity via wifi
> 
> (In reply to Justin M. Forbes from comment #15)
> I still see the same problem: the card's antennas are 0.5m (19 inches) from
> the router's antennas; wifi works from handheld devices; NetworkManager
> Settings shows "checked", locked, strongest signal; but no data flows: "ping
> <the router's numerical IP4>" shows no packets getting through.
> 
> Note the dmesg traceback beginning around:
> [   79.393402] WARNING: CPU: 2 PID: 456 at net/mac80211/rate.c:518
> ieee80211_get_tx_rates+0x273/0x7f0 [mac80211]()
> 
> The card is:
> 05:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE
> 802.11b/g/n WiFi Adapter (rev 01)
> 05:00.0 0280: 10ec:8178 (rev 01)
> 
> The kernel is:
> Linux f19s.local 3.12.6-200.fc19.x86_64 #1 SMP Mon Dec 23 16:33:38 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
Found this right after association:
[   85.646878] ------------[ cut here ]------------
[   85.646931] WARNING: CPU: 3 PID: 1898 at net/mac80211/rate.c:518 ieee80211_get_tx_rates+0x267/0x790 [mac80211]()
[   85.646935] Modules linked in: fuse(F) ebtable_nat(F) nf_conntrack_netbios_ns(F) nf_conntrack_broadcast(F) ipt_MASQUERADE(F) ip6table_nat(F) nf_nat_ipv6(F) ip6table_mangle(F) ip6t_REJECT(F) nf_conntrack_ipv6(F) nf_defrag_ipv6(F) iptable_nat(F) nf_nat_ipv4(F) nf_nat(F) iptable_mangle(F) nf_conntrack_ipv4(F) nf_defrag_ipv4(F) xt_conntrack(F) nf_conntrack(F) ebtable_filter(F) ebtables(F) bnep(F) bluetooth(F) ip6table_filter(F) ip6_tables(F) vfat(F) fat(F) snd_hda_codec_realtek(F) kvm_amd(F) snd_hda_codec_hdmi(F) kvm(F) snd_hda_intel(F) snd_hda_codec(F) snd_hwdep(F) snd_seq(F) snd_seq_device(F) crc32_pclmul(F) snd_pcm(F) arc4(F) crc32c_intel(F) rtl8192ce(F) rtl_pci(F) rtlwifi(F) rtl8192c_common(F) mac80211(F) ghash_clmulni_intel(F) snd_page_alloc(F) snd_timer(F) cfg80211(F) rfkill(F) r8169(F) mii(F)
[   85.647001]  nfsd(F) snd(F) auth_rpcgss(F) microcode(F) i2c_piix4(F) k10temp(F) shpchp(F) serio_raw(F) wmi(F) acpi_cpufreq(F) soundcore(F) mperf(F) nfs_acl(F) lockd(F) sunrpc(F) uinput(F) radeon(F) i2c_algo_bit(F) drm_kms_helper(F) ttm(F) drm(F) i2c_core(F)
[   85.647036] CPU: 3 PID: 1898 Comm: wpa_supplicant Tainted: GF            3.11.1-200.jreiser.fc19.x86_64 #1
[   85.647042] Hardware name: MSI MS-7721/FM2-A85XMA-E35 (MS-7721), BIOS V1.7 01/29/2013
[   85.647046]  0000000000000009 ffff880206525840 ffffffff816476af 0000000000000000
[   85.647055]  ffff880206525878 ffffffff810670dd ffff8801f8ec0b00 ffff8801f8ec0b30
[   85.647063]  0000000000000000 ffff8801f8ec0b3c ffff88021ca51ca8 ffff880206525888
[   85.647071] Call Trace:
[   85.647084]  [<ffffffff816476af>] dump_stack+0x45/0x56
[   85.647094]  [<ffffffff810670dd>] warn_slowpath_common+0x7d/0xa0
[   85.647101]  [<ffffffff810671ba>] warn_slowpath_null+0x1a/0x20
[   85.647132]  [<ffffffffa03aaee7>] ieee80211_get_tx_rates+0x267/0x790 [mac80211]
[   85.647142]  [<ffffffff81302dd4>] ? timerqueue_del+0x24/0x70
[   85.647173]  [<ffffffffa03ab5e2>] rate_control_get_rate+0xd2/0xe0 [mac80211]
[   85.647206]  [<ffffffffa03b97b1>] invoke_tx_handlers+0x711/0x12c0 [mac80211]
[   85.647215]  [<ffffffff811a1a51>] ? mem_cgroup_bad_page_check+0x21/0x30
[   85.647224]  [<ffffffff81144f7b>] ? get_page_from_freelist+0x5cb/0x940
[   85.647232]  [<ffffffff8109572c>] ? resched_task+0x5c/0x60
[   85.647265]  [<ffffffffa03ba3d7>] ieee80211_tx+0x77/0xf0 [mac80211]
[   85.647298]  [<ffffffffa03ba63d>] ieee80211_xmit+0x9d/0x100 [mac80211]
[   85.647329]  [<ffffffffa03bb57d>] ieee80211_subif_start_xmit+0xbad/0xd00 [mac80211]
[   85.647342]  [<ffffffff8154d268>] dev_hard_start_xmit+0x318/0x570
[   85.647352]  [<ffffffff8156b020>] sch_direct_xmit+0xe0/0x1c0
[   85.647360]  [<ffffffff8154d6b9>] dev_queue_xmit+0x1f9/0x480
[   85.647368]  [<ffffffff81630d86>] packet_sendmsg+0xd66/0xf70
[   85.647377]  [<ffffffff81533fb9>] sock_sendmsg+0x99/0xd0
[   85.647386]  [<ffffffff81165473>] ? handle_pte_fault+0x93/0xa70
[   85.647395]  [<ffffffff815344e1>] SYSC_sendto+0x121/0x1c0
[   85.647402]  [<ffffffff8116c8e7>] ? do_munmap+0x297/0x3b0
[   85.647411]  [<ffffffff81534ece>] SyS_sendto+0xe/0x10
[   85.647418]  [<ffffffff81656859>] system_call_fastpath+0x16/0x1b
[   85.647424] ---[ end trace 00f1c9e0ac78800d ]---

This seems to be a recurring issue for rtlwifi, we delved into it a while back and haven't had a chance to return.  As I recall, as adapter connects to router, begins to transmit a frame.  As this progresses, it looks up support or basic rates for the connection with router and runs into an invalid rate in the list (zero in the case I seem to recall).  This causes the warn above, pretty much paralyzing the tx side afterwards, which would cause the subsequent disconnect since stack would expect to get IP address or other task that will essentially timeout.  

I would expect the problem occurs when the internal rate struct in error gets set during assocation process, but haven't been able to confirm the problem or debug further.  These error seem to occur on more that just this flavor adapter.

At least, that's were it's been left at this point.  But a common issue that need to be addressed.  At least the description is out that.

Is this easily reproduced?  Wasn't easy to do here..

Comment 20 John Reiser 2014-01-22 22:53:35 UTC
Created attachment 854104 [details]
dmesg output: warning trace, no connectivity via wifi

This happens every time.  At boot, Settings > Network starts with Wired ON, WiFi OFF.  I turn WiFi ON, then immediately the kernel complains.  I turn Wired OFF (WiFi is still ON), then "ping <numeric IP4 of router>" drops all packets.  I turn Wired ON (both are now ON) and network traffic flows properly down the Wired interface.

Comment 21 Justin M. Forbes 2014-03-10 14:47:06 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 19 kernel bugs.

Fedora 19 has now been rebased to 3.13.5-100.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 22 Mohammed Arafa 2014-03-10 15:33:18 UTC
yes still applicable

Comment 23 Justin M. Forbes 2014-05-21 19:30:46 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 19 kernel bugs.

Fedora 19 has now been rebased to 3.14.4-100.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 24 Mohammed Arafa 2014-05-29 02:27:20 UTC
still applicable

Comment 25 Fedora End Of Life 2015-01-09 19:31:45 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 26 Fedora End Of Life 2015-02-17 16:50:40 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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