Bug 970838 - rtl8192cu driver does not work, loses network connectivity after minutes
Summary: rtl8192cu driver does not work, loses network connectivity after minutes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: fedora-kernel-wireless-realtek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-05 03:56 UTC by Christian
Modified: 2014-02-05 21:40 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 21:40:47 UTC
Type: Bug


Attachments (Terms of Use)

Description Christian 2013-06-05 03:56:19 UTC
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):
3.9.4-200.fc18.x86_64

How reproducible:
100%.

Steps to Reproduce:
1. Connect to WiFi network via NetworkManager.
2. Use network connection for a brief amount of time.

Actual results:
Connectivity stalls after a few minutes.

Expected results:
A stable WiFi connection would be nice...

Additional info:

$ 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)
Release:        18
Codename:       SphericalCow

$ lsusb
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
943e9b714a926e630b8152d7aad91d2e  /usr/lib/firmware/rtlwifi/rtl8192cufw.bin

lshw snippet:
           *-network
                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
                version: 02
                serial: 00:21:70:3d:6c:83
                size: 10Mbit/s
                capacity: 1Gbit/s
                width: 64 bits
                clock: 33MHz
                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)

Comment 1 Christian 2013-06-10 05:46:41 UTC
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.

Comment 2 Justin M. Forbes 2013-10-18 21:06:20 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 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.

Comment 3 Rob 2013-10-28 02:58:12 UTC
I followed the instructions at this link: 

https://github.com/pvaret/rtl8192cu-fixes

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.

Comment 4 David A. De Graaf 2013-11-21 15:56:59 UTC
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.

Comment 5 Chris Ferraro 2013-12-19 13:05:43 UTC
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.

Comment 6 Fedora End Of Life 2013-12-21 13:52:05 UTC
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.

Comment 7 Fedora End Of Life 2014-02-05 21:40:47 UTC
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
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.