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:
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?
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
Created attachment 788822 [details] dmesg wifi dmesg wifi
Created attachment 788823 [details] messages for wifi messages for wifi
this is frustrating. the desktop is only 5 feet away from the access point and it has horrible speeds
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.
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
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.
kernel-3.10.7-200.fc19.x86_64
*********** 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.
[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.
Created attachment 804725 [details] dmesg output
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.
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.
*********** 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.
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
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%.
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 :(
(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..
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.
*********** 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.
yes still applicable
*********** 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.
still applicable
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.
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.