Description of problem:
I just got an ASUS USB-N13 wifi USB stick. It uses the rtl8192cu driver. On a fully up-to-date Fedora 18 desktop (kernel 3.9.4-200), I get a connection to my WPA-protected home network without any problems, but after some time between seconds and a few minutes I lose connectivity -- I can neither reach any systems nor can any systems reach the machine using the ASUS stick. The interface remains up, I can tcpdump etc, it's just that the packets seemingly go into a void. I have to disconnect in NetworkManager, re-connect, and get another few minutes.
This is absolutely reproducible, the only difference is the number of minutes until things break. I can rule out problems elsewhere, as the various other wireless devices I have in the home work fine, at considerably worse signal strength.
I have previously reported this in bug 789605, but that ticket is closed and nobody seems to follow up. :( In case I have more luck here, let me know what I can provide to help.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Connect to WiFi network via NetworkManager.
2. Use network connection for a brief amount of time.
Connectivity stalls after a few minutes.
A stable WiFi connection would be nice...
$ uname -a
Linux home 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: Fedora
Description: Fedora release 18 (Spherical Cow)
Bus 001 Device 005: ID 0b05:17ab ASUSTek Computer, Inc. USB-N13 802.11n Network Adapter (rev. B1) [Realtek RTL8192CU]
(Other devices snipped)
$ md5sum /usr/lib/firmware/rtlwifi/rtl8192cufw.bin
description: Ethernet interface
product: RTL8111/8168 PCI Express Gigabit Ethernet controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:03:00.0
logical name: eth0
width: 64 bits
capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=half latency=0 link=no multicast=yes port=MII speed=10Mbit/s
resources: irq:44 ioport:d800(size=256) memory:feaff000-feafffff memory:fdff0000-fdffffff memory:feac0000-feadffff
After a disconnect, dmesg shows nothing particularly helpful:
[201120.786665] wlan0: authenticate with 20:4e:7f:91:a3:31
[201120.798634] wlan0: send auth to 20:4e:7f:91:a3:31 (try 1/3)
[201120.801217] wlan0: authenticated
[201120.802018] wlan0: associate with 20:4e:7f:91:a3:31 (try 1/3)
[201120.805585] wlan0: RX AssocResp from 20:4e:7f:91:a3:31 (capab=0x411 status=0 aid=2)
[201120.805616] wlan0: associated
[201120.805673] cfg80211: Calling CRDA for country: US
[201120.811612] cfg80211: Regulatory domain changed to country: US
[201120.811617] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[201120.811619] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[201120.811622] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[201120.811624] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201120.811627] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201120.811629] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201120.811631] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[201120.811634] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
This follows when I initiate the disconnect:
[201912.307377] wlan0: deauthenticating from 20:4e:7f:91:a3:31 by local choice (reason=3)
[201912.320774] cfg80211: Calling CRDA to update world regulatory domain
[201912.433991] cfg80211: World regulatory domain updated:
[201912.433995] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[201912.433997] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201912.433999] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201912.434034] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[201912.434037] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201912.434039] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
And then reconnect:
[201915.579402] wlan0: authenticate with 20:4e:7f:91:a3:31
[201915.592089] wlan0: send auth to 20:4e:7f:91:a3:31 (try 1/3)
[201915.598503] wlan0: authenticated
[201915.599071] wlan0: associate with 20:4e:7f:91:a3:31 (try 1/3)
[201915.623239] wlan0: RX AssocResp from 20:4e:7f:91:a3:31 (capab=0x411 status=0 aid=2)
[201915.623277] wlan0: associated
[201915.623800] cfg80211: Calling CRDA for country: US
[201915.630041] cfg80211: Regulatory domain changed to country: US
[201915.630045] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[201915.630048] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
[201915.630051] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
[201915.630053] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201915.630056] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201915.630058] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[201915.630060] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
[201915.630062] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
Fyi, at this point I have Realtek's driver working fine with the same kernel, so it's certainly a problem in the driver included with Linux.
*********** 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 18 kernel bugs.
Fedora 18 has now been rebased to 3.11.4-101.fc18. 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 19, and are still experiencing this issue, please change the version to Fedora 19.
If you experience different issues, please open a new bug report for those.
I followed the instructions at this link:
and the Edimax-EW7811Un now works with 3.11.4-201.fc19.x86_64. I've been trying to get this USB adapter to work going all the way back to FC17, and it finally works now using this repaired driver. I was previously unable to build the driver from source provided by Realtek. As desribed at the link above, in the os_dep/linux/os_intfs.c file rtw_proc_init_one and rtw_proc_remove_one were disabled to allow the module to compile.
As stated at the link above, as it currently stands, the driver from Realtek doesn't populate /proc with informational data from the driver. The API for /proc has changed, and the driver hasn't yet been ported to the new API.
The driver rtl8192cu that comes with the kernel 3.11.4-201.fc19.x86_64 still does not work, disconnecting shortly after connecting. Strangely though, it works with the Live Fedora 19 but not when installed to the hard drive.
My Rosewill RNX-N250UBE Wireless N USB adapter now can be used, thanks to the instructions linked in Comment 3. It is identified by lsusb as
Bus 002 Device 002: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
This non-standard (non-rpm) installation even survived the yum upgrade to kernel-3.11.8-200.fc19.x86_64, presumably due to the 'sudo dkms add ./rtl8192cu-fixes' element of the installation procedure.
I do hope this fixed driver will make it very soon into the standard kernel modules. It seems to work very well.
This BZ certainly applies to Fedora 19, but I don't know how to change that.
Bug still present using kernel 3.11.10-200/Fedora 19.
No idea how to change this to Fedora 19.
I'm not exactly a guru at fixing/working through driver compilation issues, even with the listed solution link in comment 3, so I hope that this gets fixed soon...it's not like online sellers list which chipset a particular wireless NIC uses.
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.
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 prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 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 to Fedora 18's end of life.
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 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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
Thank you for reporting this bug and we are sorry it could not be fixed.