This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 789605 - rtl8192cu: After 5~6 minutes, wireless usb lancard doesn't work (cannot connect internet).
rtl8192cu: After 5~6 minutes, wireless usb lancard doesn't work (cannot conne...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
18
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: John Greene
Fedora Extras Quality Assurance
:
: 806142 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-11 12:35 EST by sangu
Modified: 2013-10-18 20:11 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-03 00:22:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/messages (28.32 KB, text/plain)
2012-02-11 12:51 EST, sangu
no flags Details
dmesg (122.77 KB, text/plain)
2012-02-11 12:52 EST, sangu
no flags Details
/var/log/messages (28.52 KB, text/plain)
2012-02-23 03:22 EST, sangu
no flags Details
Patch to prevent RCR mistake (937 bytes, patch)
2012-04-06 18:13 EDT, Larry Finger
no flags Details | Diff
Revised patch to prevent RCR mistake (931 bytes, text/plain)
2012-04-10 11:20 EDT, Larry Finger
no flags Details
While connecting Network with wirelesscard, /var/log/messages (14.88 KB, text/plain)
2012-04-10 21:53 EDT, sangu
no flags Details
When wireless usb land card can't connect internet, /var/log/messages in $ifdown wlan0 (3.29 KB, text/plain)
2012-04-10 22:19 EDT, sangu
no flags Details
While executing $ ifup wlan0, /var/log/messages. (7.83 KB, text/plain)
2012-04-10 22:27 EDT, sangu
no flags Details
/var/log/messages in 3.9.0-0.rc4.git0.1.fc19.x86_64 (15.14 KB, text/plain)
2013-04-01 22:29 EDT, sangu
no flags Details
/var/log/messages in kernel-3.8.5-201.fc18.x86_64 (14.96 KB, text/plain)
2013-04-02 01:53 EDT, sangu
no flags Details
grep NetworkManager /var/log/messages (16.63 KB, text/plain)
2013-04-10 21:40 EDT, Leif Gruenwoldt
no flags Details
Patch to improve automatic gain control (71.10 KB, patch)
2013-09-26 15:58 EDT, Larry Finger
no flags Details | Diff
Patch to improve automatic gain control - revised (70.57 KB, patch)
2013-09-26 17:57 EDT, Larry Finger
no flags Details | Diff

  None (edit)
Description sangu 2012-02-11 12:35:55 EST
Description of problem:
After 5~6 minutes, wireless usb lancard doesn't work (cannot connect internet).
Then, after uses ping command, wireless usb lancard works well, again.

wireless usb lancard chip : rtl8192cu

Version-Release number of selected component (if applicable):
3.2.5-3.fc16.x86_64

How reproducible:
always

Steps to Reproduce:
1. Insert wireless usb lancard.
2. cannot connect webpage 
3. ping www.google.com
  
Actual results:


Expected results:


Additional info:
Comment 1 sangu 2012-02-11 12:51:23 EST
Created attachment 561118 [details]
/var/log/messages
Comment 2 sangu 2012-02-11 12:52:09 EST
Created attachment 561119 [details]
dmesg
Comment 3 John W. Linville 2012-02-13 10:31:16 EST
Larry, the kernel involved is using the compat-wireless-3.3-rc1-2 snapshot with a series of fix patches on top:

# Pending upstream fixes
Patch50101: mac80211-fix-debugfs-key-station-symlink.patch
Patch50102: brcmsmac-fix-tx-queue-flush-infinite-loop.patch
Patch50103: mac80211-Use-the-right-headroom-size-for-mesh-mgmt-f.patch
Patch50105: b43-add-option-to-avoid-duplicating-device-support-w.patch
Patch50106: mac80211-update-oper_channel-on-ibss-join.patch
Patch50107: mac80211-set-bss_conf.idle-when-vif-is-connected.patch
Patch50108: iwlwifi-fix-PCI-E-transport-inta-race.patch
Patch50109: bcma-Fix-mem-leak-in-bcma_bus_scan.patch
Patch50110: rt2800lib-fix-wrong-128dBm-when-signal-is-stronger-t.patch
Patch50111: iwlwifi-make-Tx-aggregation-enabled-on-ra-be-at-DEBU.patch
Patch50112: ssb-fix-cardbus-slot-in-hostmode.patch
Patch50113: iwlwifi-don-t-mess-up-QoS-counters-with-non-QoS-fram.patch
Patch50114: mac80211-timeout-a-single-frame-in-the-rx-reorder-bu.patch

Patch50200: ath9k-use-WARN_ON_ONCE-in-ath_rc_get_highest_rix.patch
Patch50201: ath9k-fix-a-WEP-crypto-related-regression.patch
Patch50202: ath9k_hw-fix-a-RTS-CTS-timeout-regression.patch

Patch50300: brcm80211-smac-fix-endless-retry-of-A-MPDU-transmissions.patch
Comment 4 Larry Finger 2012-02-13 11:15:11 EST
In your dmesg output, many of the deauthentications are for reason 3, which means "Deauthenticated because sending station is leaving (or has left) IBSS or ESS". This reason is common.

You also have deauth for reason 7, which means "Class 3 frame received from nonassociated station". I have never seen this one on my system.

What I think gives some indication of the problem are the other 2 reasons for deauth: 14 "MIC failure." and 15 "4-Way Handshake timeout". These indicate a failure in WPA or WPA2 encryption - I don't know which version you are using.

Please check your firmware by running the command
md5sum /lib/firmware/rtlwifi/rtl8192cufw.bin

The result should be 943e9b714a926e630b8152d7aad91d2e. If yours is different, the file has been corrupted and needs to be replaced.

If your firmware is OK, there is a possibility that the hardware is failing. The need for a ping may indicate that the encryption engine needs to send an unencrypted packet to clear it.
Comment 5 sangu 2012-02-13 12:26:59 EST
$ md5sum /lib/firmware/rtlwifi/rtl8192cufw.bin
943e9b714a926e630b8152d7aad91d2e  /lib/firmware/rtlwifi/rtl8192cufw.bin
$ rpm -qf /lib/firmware/rtlwifi/rtl8192cufw.bin
linux-firmware-20120206-0.1.git06c8f81.fc16.noarch

insert wireless usb lancard
http://www.fpaste.org/v9Eo/  /var/log/messages 

wireless usb lancard doesn't work. 
popup password dialog.
http://www.fpaste.org/DpYi/  /var/log/messages

$ rpm -q NetworkManager
NetworkManager-0.9.2-1.fc16.x86_64
Comment 6 Larry Finger 2012-02-13 12:53:58 EST
OK, your firmware should be good.

In the /var/log/messages output you provided, I see no indication that your interface received any packets. If is trying to associate, but the process is timing out. When you run 'iwlist scan', do you see anything?

The contents of /var/log/NetworkManager might also be useful.

Do you have another system running from the AP? Can we rule difficulties in the AP? If you have another system, would it be suitable for running Wireshark to capture the on-air traffic?
Comment 7 sangu 2012-02-14 20:26:15 EST
rtl8192cu wireless landcard iptime n300u
http://contents.iptime.co.kr/~contents/home/gallery/n300u/n300u_gallery_01.jpg

In windows xp
The wireless usb lancard works well. 
The LED lamp on usb landcard  flickers.

Then, the LED lamp is always on in Linux.

$ iwlist wlan0 scan http://www.fpaste.org/mdPg/
Comment 8 Larry Finger 2012-02-14 20:40:51 EST
The LED information is irrelevant. Most people don't like the blinking, which is why it was programmed to be on when connected, and off when not.

I asked for /var/log/NetworkManager output.
Comment 9 sangu 2012-02-14 21:31:52 EST
(In reply to comment #8)
> The LED information is irrelevant. Most people don't like the blinking, which
> is why it was programmed to be on when connected, and off when not.
> 
> I asked for /var/log/NetworkManager output.
NetworkManager file isn't in /var/log.
Comment 10 Larry Finger 2012-02-14 21:51:27 EST
Anyone know where Fedora logs the NetworkManager data?
Comment 11 Josh Boyer 2012-02-15 09:26:11 EST
(In reply to comment #10)
> Anyone know where Fedora logs the NetworkManager data?

It just logs to /var/log/messages
Comment 12 Larry Finger 2012-02-15 10:13:57 EST
Thanks for the info.
Comment 13 sangu 2012-02-23 03:22:28 EST
Created attachment 565223 [details]
/var/log/messages

$ NM_SERIAL_DEBUG=1 NM_PPP_DEBUG=1 /usr/sbin/NetworkManager restart
insert rtl8192cu wireless usb lancard.
$tail -f /var/log/messages
$ uname -r
3.2.7-1.fc16.x86_64

$ lsusb -v
[...]

Bus 002 Device 005: ID 0bda:8178 Realtek Semiconductor Corp. 
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0x8178 
  bcdDevice            2.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           46
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           4
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Comment 14 Jirka Klimes 2012-03-26 06:53:28 EDT
*** Bug 806142 has been marked as a duplicate of this bug. ***
Comment 15 Larry Finger 2012-04-06 18:13:26 EDT
Created attachment 575836 [details]
Patch to prevent RCR mistake

The rtl8192cu driver incorrectly sets the Receive Control Register in some situations. This patch prevents the condition.
Comment 16 sangu 2012-04-10 01:41:36 EDT
This issue still happens in kernel-3.3.1-3.fc17.x86_64.

When does this patch apply to kernel package?
Comment 17 Josh Boyer 2012-04-10 09:59:23 EDT
(In reply to comment #16)
> This issue still happens in kernel-3.3.1-3.fc17.x86_64.
> 
> When does this patch apply to kernel package?

I will try to get it included later today.
Comment 18 Larry Finger 2012-04-10 11:20:41 EDT
Created attachment 576495 [details]
Revised patch to prevent RCR mistake

The original patch had a bug that made it do nothing. A revised one is now posted.
Comment 19 Josh Boyer 2012-04-10 15:04:22 EDT
I had to rework the latest patch in comment #18 slightly to apply to a 3.3.1 kernel.  I've started a scratch build here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3977542

Sangu, it would be very helpful if you could download the kernel from that and test it when it completes building.
Comment 20 sangu 2012-04-10 21:53:22 EDT
Created attachment 576638 [details]
While connecting Network with wirelesscard, /var/log/messages

This bug still happens in 3.3.1-5.1.fc16.x86_64.

$ dmesg
[...]
 184.665308] usb 2-5: new high-speed USB device number 3 using ehci_hcd
[  184.782050] usb 2-5: New USB device found, idVendor=0bda, idProduct=8178
[  184.782058] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  184.782062] usb 2-5: Product: 802.11n WLAN Adapter
[  184.782066] usb 2-5: Manufacturer: Realtek
[  184.782069] usb 2-5: SerialNumber: 00e04c000001
[  184.901997] cfg80211: Calling CRDA to update world regulatory domain
[  184.956923] cfg80211: World regulatory domain updated:
[  184.956929] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[  184.956935] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  184.956940] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[  184.956944] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[  184.956948] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  184.956952] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  185.013423] rtl8192cu: rtl8192cu: Chip version 0x11
[  185.089923] rtl8192cu: MAC address: 00:26:66:49:6d:97
[  185.089932] rtl8192cu: Board Type 0
[  185.089958] Loading firmware rtlwifi/rtl8192cufw.bin
[  185.090310] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1
[  185.090396] usbcore: registered new interface driver rtl8192cu
[  185.141034] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[  185.142672] rtlwifi: wireless switch is on
[  185.158294] rtl8192cu: MAC auto ON okay!
[  185.190317] cfg80211: Calling CRDA for country: KR
[  185.193403] cfg80211: Regulatory domain changed to country: KR
[  185.193408] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[  185.193413] cfg80211:   (2402000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
[  185.193418] cfg80211:   (5170000 KHz - 5250000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[  185.193422] cfg80211:   (5250000 KHz - 5330000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[  185.193426] cfg80211:   (5490000 KHz - 5630000 KHz @ 20000 KHz), (300 mBi, 3000 mBm)
[  185.193430] cfg80211:   (5735000 KHz - 5815000 KHz @ 20000 KHz), (300 mBi, 3000 mBm)
[  185.194052] rtl8192cu: Tx queue select: 0x05
[  185.563620] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  187.379548] wlan0: authenticate with 00:26:66:e0:52:9a (try 1)
[  187.382196] wlan0: authenticated
[  187.405550] wlan0: associate with 00:26:66:e0:52:9a (try 1)
[  187.412263] wlan0: RX AssocResp from 00:26:66:e0:52:9a (capab=0x411 status=0 aid=3)
[  187.412269] wlan0: associated
[  187.412274] wlan0: moving STA 00:26:66:e0:52:9a to state 1
[  187.412278] wlan0: moving STA 00:26:66:e0:52:9a to state 2
[  187.426544] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  187.445300] wlan0: moving STA 00:26:66:e0:52:9a to state 3
[  197.730108] wlan0: no IPv6 routers present
Comment 21 sangu 2012-04-10 22:19:00 EDT
Created attachment 576640 [details]
When wireless usb land card can't connect internet,  /var/log/messages in $ifdown wlan0
Comment 22 sangu 2012-04-10 22:27:06 EDT
Created attachment 576642 [details]
While executing $ ifup wlan0,  /var/log/messages.
Comment 23 sangu 2012-05-18 02:10:22 EDT
This bug still happens in 3.3.4-5.fc17.x86_64.
Comment 24 sangu 2012-07-13 23:37:57 EDT
Still happens in 3.4.4-5.fc17.x86_64
Comment 25 Josh Boyer 2012-09-10 10:09:30 EDT
Larry, any further thoughts on this one?
Comment 26 Dave Jones 2012-10-23 11:37:50 EDT
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Comment 27 sangu 2012-10-24 22:53:09 EDT
Open new bug 869870
Comment 28 Leif Gruenwoldt 2012-12-17 16:50:22 EST
FWIW, this chipset still has problems in Fedora 18 beta out of the box. 

I did find a workaround (tested on Fedora 17) that involves using the Linux drivers from Realtek.

http://ipcctvsoft.blogspot.ca/2012/01/linux-rtl8192cu-nightmare-gone.html
Comment 29 Fedora End Of Life 2013-01-16 17:51:12 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. 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 '16'.

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 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 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 to click on 
"Clone This Bug" and open it against that version of Fedora.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 30 sangu 2013-01-17 00:48:17 EST
This bug still happens in fedora 18.

kernel-3.7.2-201.fc18.x86_64
Comment 31 John Greene 2013-01-17 09:41:38 EST
Would add that deauth 3 can occur either by STA choosing to leave or AP kicking STA off, not always clear in logs of older supplicant which actually occurred.  Needs a sniffer see for sure. 

 If AP initiates a deauth, the STA may kick out a frame before it processes the deauth from AP.  To which the AP will respond with "Class 3 frame received from nonassociated station".  To the AP, you are no longer associated, so why are you sending me a NULL frame as if you were?  This was common on some TI cards I've worked in the past and perhaps the case here.  Probably a firmware change needed for this, in the end, ignorable usually.


(In reply to comment #4)
> In your dmesg output, many of the deauthentications are for reason 3, which
> means "Deauthenticated because sending station is leaving (or has left) IBSS
> or ESS". This reason is common.
> 
> You also have deauth for reason 7, which means "Class 3 frame received from
> nonassociated station". I have never seen this one on my system.
> 
> What I think gives some indication of the problem are the other 2 reasons
> for deauth: 14 "MIC failure." and 15 "4-Way Handshake timeout". These
> indicate a failure in WPA or WPA2 encryption - I don't know which version
> you are using.
> 
> Please check your firmware by running the command
> md5sum /lib/firmware/rtlwifi/rtl8192cufw.bin
> 
> The result should be 943e9b714a926e630b8152d7aad91d2e. If yours is
> different, the file has been corrupted and needs to be replaced.
> 
> If your firmware is OK, there is a possibility that the hardware is failing.
> The need for a ping may indicate that the encryption engine needs to send an
> unencrypted packet to clear it.
Comment 32 John Greene 2013-01-17 10:06:17 EST
As I look at logs, it's seems the deauth 3 are largely from local STA choice (which can be for number of reasons: low signal, can't get IP address due to  wrong security credentials, and the list goes on).  These are hard to whittle down to the core issue.  Can you run wpa_supplicant with a -dd option to increase it's verbosity and send a log?  Might help determine why the local deauth 3's.
Comment 33 Bijju 2013-03-28 18:02:30 EDT
Any Solution for fedora 18 x86_64

Hardware/Chipset Info:
ASUS USB-N13 B1
Realtek rtl8192cu 

Problem:
USB recognized lsusb:
Bus 003 Device 003: ID 0b05:17ab ASUSTek Computer, Inc. USB-N13 802.11n Network Adapter (rev. B1) [Realtek RTL8192CU]

Driver loaded lsmod:
$ lsmod | grep -i 8192
rtl8192cu              67699  0 
rtlwifi                78178  1 rtl8192cu
rtl8192c_common        46052  1 rtl8192cu
mac80211              578735  4 rtlwifi,iwldvm,rtl8192c_common,rtl8192cu


Md5sum:
$ md5sum /lib/firmware/rtlwifi/rtl8192cufw.bin
943e9b714a926e630b8152d7aad91d2e  /lib/firmware/rtlwifi/rtl8192cufw.bin

dmesg info:
dmesg | grep -i 'wlan1'
[29363.560014] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[29365.374931] wlan1: authenticate with c8:d7:19:ab:99:0c
[29365.398696] wlan1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[29365.433065] wlan1: send auth to c8:d7:19:ab:99:0c (try 1/3)
[29365.435324] wlan1: authenticated
[29365.436407] wlan1: associate with c8:d7:19:ab:99:0c (try 1/3)
[29365.446830] wlan1: RX AssocResp from c8:d7:19:ab:99:0c (capab=0x411 status=0 aid=2)
[29365.447651] wlan1: associated
[29365.447711] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[29770.490419] wlan1: deauthenticating from c8:d7:19:ab:99:0c by local choice (reason=3)
[29815.569921] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[29817.387661] wlan1: authenticate with c8:d7:19:ab:99:0c
[29817.411188] wlan1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[29817.445455] wlan1: send auth to c8:d7:19:ab:99:0c (try 1/3)
[29817.448178] wlan1: authenticated
[29817.449100] wlan1: associate with c8:d7:19:ab:99:0c (try 1/3)
[29817.457194] wlan1: RX AssocResp from c8:d7:19:ab:99:0c (capab=0x411 status=0 aid=2)
[29817.458146] wlan1: associated
[29817.458208] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[30354.875566] wlan1: deauthenticated from c8:d7:19:ab:99:0c (Reason: 16)

Tried to install realtek drivers... make errors...  Struck with no luck....
Bought another Wireless Linksys AE2500 no luck.... full disappointment.....

Finally Wireless does not work.... help plz...

Thanks in advance for Solution [hopefully]
B
Comment 34 Bijju 2013-03-28 18:03:46 EDT
Missing Kernel Info:
3.8.4-202.fc18.x86_64

Thanks
B
Comment 35 Larry Finger 2013-03-28 18:11:24 EDT
This problem should be fixed in kernel 3.9-rc4.
Comment 36 Larry Finger 2013-03-28 18:33:35 EDT
The fix is now in 3.8.5.
Comment 37 Josh Boyer 2013-03-29 10:38:10 EDT
(In reply to comment #36)
> The fix is now in 3.8.5.

Both F17 and F18 are now on 3.8.5 in koji.  Thanks for pointing this out.
Comment 38 Fedora Update System 2013-04-01 09:29:35 EDT
kernel-3.8.5-201.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.8.5-201.fc18
Comment 39 Fedora Update System 2013-04-01 18:33:29 EDT
Package kernel-3.8.5-201.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.8.5-201.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-4645/kernel-3.8.5-201.fc18
then log in and leave karma (feedback).
Comment 40 sangu 2013-04-01 22:29:32 EDT
Created attachment 730534 [details]
/var/log/messages in 3.9.0-0.rc4.git0.1.fc19.x86_64

After a few minutes, wireless usb landcard does not work in 3.9.0-0.rc4.git0.1.fc19.x86_64.

The next time, I will in 3.8.5-201.fc18.x86_64.
Comment 41 sangu 2013-04-02 01:53:30 EDT
Created attachment 730606 [details]
/var/log/messages in kernel-3.8.5-201.fc18.x86_64

Unfortunately, after a few minutes, usb land card doesn't work.

After doing ifconfig down/up, usb land card works, and after a few minutes, usb land card doesnot work again.

ifconfig down/up -> /var/log/messages 
Apr  2 14:39:48 None kernel: [  494.989016] wlp0s29u1u5u2: deauthenticating from 00:26:66:e0:52:9a by local choice (reason=3)
Apr  2 14:39:48 None kernel: [  495.010168] cfg80211: Calling CRDA to update world regulatory domain
Apr  2 14:39:48 None avahi-daemon[422]: Interface wlp0s29u1u5u2.IPv4 no longer relevant for mDNS.
Apr  2 14:39:48 None kernel: [  495.041819] cfg80211: World regulatory domain updated:
Apr  2 14:39:48 None kernel: [  495.041824] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Apr  2 14:39:48 None kernel: [  495.041828] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr  2 14:39:48 None kernel: [  495.041831] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr  2 14:39:48 None kernel: [  495.041834] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Apr  2 14:39:48 None kernel: [  495.041837] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr  2 14:39:48 None kernel: [  495.041841] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr  2 14:39:48 None kernel: [  495.041857] cfg80211: Calling CRDA for country: KR
Apr  2 14:39:48 None dhclient[2157]: receive_packet failed on wlp0s29u1u5u2: Network is down
Apr  2 14:39:48 None avahi-daemon[422]: Leaving mDNS multicast group on interface wlp0s29u1u5u2.IPv4 with address 192.168.1.3.
Apr  2 14:39:48 None avahi-daemon[422]: Withdrawing address record for fe80::226:66ff:fe49:6d97 on wlp0s29u1u5u2.
Apr  2 14:39:48 None avahi-daemon[422]: Withdrawing address record for 192.168.1.3 on wlp0s29u1u5u2.
Apr  2 14:39:48 None avahi-daemon[422]: Joining mDNS multicast group on interface wlp0s29u1u5u2.IPv4 with address 192.168.1.3.
Apr  2 14:39:48 None avahi-daemon[422]: New relevant interface wlp0s29u1u5u2.IPv4 for mDNS.
Apr  2 14:39:48 None kernel: [  495.045519] cfg80211: Regulatory domain changed to country: KR
Apr  2 14:39:48 None kernel: [  495.045523] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Apr  2 14:39:48 None kernel: [  495.045525] cfg80211:   (2402000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
Apr  2 14:39:48 None kernel: [  495.045528] cfg80211:   (5170000 KHz - 5250000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Apr  2 14:39:48 None kernel: [  495.045530] cfg80211:   (5250000 KHz - 5330000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Apr  2 14:39:48 None kernel: [  495.045531] cfg80211:   (5490000 KHz - 5630000 KHz @ 20000 KHz), (300 mBi, 3000 mBm)
Apr  2 14:39:48 None kernel: [  495.045533] cfg80211:   (5735000 KHz - 5815000 KHz @ 20000 KHz), (300 mBi, 3000 mBm)
Apr  2 14:39:48 None avahi-daemon[422]: Registering new address record for 192.168.1.3 on wlp0s29u1u5u2.IPv4.
Apr  2 14:39:48 None NetworkManager[454]: <info> (wlp0s29u1u5u2): supplicant interface state: completed -> disabled
Apr  2 14:39:52 None kernel: [  499.590018] rtl8192cu: MAC auto ON okay!
Apr  2 14:39:52 None kernel: [  499.622636] rtl8192cu: Tx queue select: 0x05
Apr  2 14:39:53 None kernel: [  499.990003] IPv6: ADDRCONF(NETDEV_UP): wlp0s29u1u5u2: link is not ready
Apr  2 14:39:53 None NetworkManager[454]: <info> (wlp0s29u1u5u2): supplicant interface state: disabled -> scanning
Apr  2 14:39:54 None kernel: [  500.772483] wlp0s29u1u5u2: authenticate with 00:26:66:e0:52:9a
Apr  2 14:39:54 None kernel: [  500.783592] wlp0s29u1u5u2: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
Apr  2 14:39:54 None NetworkManager[454]: <info> (wlp0s29u1u5u2): supplicant interface state: scanning -> authenticating
Apr  2 14:39:54 None kernel: [  500.795588] wlp0s29u1u5u2: send auth to 00:26:66:e0:52:9a (try 1/3)
Apr  2 14:39:54 None kernel: [  500.798088] wlp0s29u1u5u2: authenticated
Apr  2 14:39:54 None kernel: [  500.798431] wlp0s29u1u5u2: associate with 00:26:66:e0:52:9a (try 1/3)
Apr  2 14:39:54 None NetworkManager[454]: <info> (wlp0s29u1u5u2): supplicant interface state: authenticating -> associating
Apr  2 14:39:54 None kernel: [  500.809614] wlp0s29u1u5u2: RX AssocResp from 00:26:66:e0:52:9a (capab=0x411 status=0 aid=4)
Apr  2 14:39:54 None kernel: [  500.809657] wlp0s29u1u5u2: associated
Apr  2 14:39:54 None kernel: [  500.809668] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s29u1u5u2: link becomes ready
Apr  2 14:39:54 None NetworkManager[454]: <info> (wlp0s29u1u5u2): supplicant interface state: associating -> associated
Apr  2 14:39:54 None NetworkManager[454]: <info> (wlp0s29u1u5u2): supplicant interface state: associated -> 4-way handshake
Apr  2 14:39:54 None NetworkManager[454]: <info> (wlp0s29u1u5u2): supplicant interface state: 4-way handshake -> completed
Apr  2 14:39:56 None avahi-daemon[422]: Registering new address record for fe80::226:66ff:fe49:6d97 on wlp0s29u1u5u2.*.
Comment 42 Fedora Update System 2013-04-03 00:22:31 EDT
kernel-3.8.5-201.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 43 Bijju 2013-04-03 15:55:37 EDT
Hi

I have updated to the new kernel "3.8.5-201.fc18.x86_64" and problem still persists. Same issue, connects to the network... first few mins it works good... and then nothing ..... it fails again....

Thanks
Chandra
Comment 44 Bijju 2013-04-03 16:53:21 EDT
Hi 

Internet works sometime and as soon as i leave for few mins... its gone again.. and my gnome crashes ...
First Connection Status:
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan1'
[   13.806575] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[   15.411108] wlan1: authenticate with c8:d7:19:ab:99:0c
[   15.421179] wlan1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[   15.433560] wlan1: send auth to c8:d7:19:ab:99:0c (try 1/3)
[   15.453288] wlan1: authenticated
[   15.453775] wlan1: associate with c8:d7:19:ab:99:0c (try 1/3)
[   15.472309] wlan1: RX AssocResp from c8:d7:19:ab:99:0c (capab=0x411 status=0 aid=2)
[   15.472425] wlan1: associated
[   15.472532] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[   95.915173] wlan1: deauthenticating from c8:d7:19:ab:99:0c by local choice (reason=3)
[  118.392033] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[  120.025227] wlan1: authenticate with c8:d7:19:ab:99:0c
[  120.025246] wlan1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[  120.037610] wlan1: send auth to c8:d7:19:ab:99:0c (try 1/3)
[  120.049551] wlan1: authenticated
[  120.050500] wlan1: associate with c8:d7:19:ab:99:0c (try 1/3)
[  120.093418] wlan1: RX AssocResp from c8:d7:19:ab:99:0c (capab=0x411 status=0 aid=2)
[  120.093515] wlan1: associated
[  120.093536] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[  312.668377] wlan1: deauthenticating from c8:d7:19:ab:99:0c by local choice (reason=3)
[24039.734220] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[24041.355533] wlan1: authenticate with c8:d7:19:ab:99:0c
[24041.366353] wlan1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[24041.379116] wlan1: send auth to c8:d7:19:ab:99:0c (try 1/3)
[24041.381220] wlan1: authenticated
[24041.381799] wlan1: associate with c8:d7:19:ab:99:0c (try 1/3)
[24041.411060] wlan1: RX AssocResp from c8:d7:19:ab:99:0c (capab=0x411 status=0 aid=4)
[24041.411165] wlan1: associated
[24041.411188] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready



Then nothing works... i tried the dmesg to look what is happening...
dmesg does not even have a record for my wlan
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan1'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan1'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan1'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan1'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan0'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan1'
[bijju@bijju-Mint14-Dell-System-XPS-L502X ~]$ dmesg | grep -i 'wlan0'


Help Please.... :(

Thanks
B
Comment 45 Larry Finger 2013-04-03 18:07:48 EDT
I have no idea what is wrong with your system. After applying the fix that went into the new kernel, my device that uses rtl8192cu maintained a connection for 20 hours without a single drop.

You need to post the portion of dmesg that happens *AFTER* the drop occurs. Nothing is logged using wlanX, thus your attempts above were bound to fail.
Comment 46 Bijju 2013-04-04 10:16:30 EDT
Hi Larry,

It show to me as well as connected: 

Ping Status (and some time it goes up to 88% packet loss):
[bijju@bijju-myDesktop .themes]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=19.6 ms
.
.
.
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=55.4 ms
^C
--- 192.168.1.1 ping statistics ---
39 packets transmitted, 38 received, 2% packet loss, time 38050ms
rtt min/avg/max/mdev = 1.748/20.163/138.910/29.757 ms


[bijju@bijju-myDesktop .themes]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=9.47 ms
.
.
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=432 ms
^C
--- 192.168.1.1 ping statistics ---
8 packets transmitted, 7 received, 12% packet loss, time 7001ms
rtt min/avg/max/mdev = 9.478/482.789/1318.543/373.260 ms, pipe 2



DMESG info:
[bijju@bijju-myDesktop ~]$ dmesg | grep -i wlan
[    2.605150] usb 2-1.6: Product: 802.11n WLAN Adapter
[    8.338918] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   33.539501] wlan0: authenticate with c8:d7:19:ab:99:0c
[   33.550839] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[   33.563042] wlan0: send auth to c8:d7:19:ab:99:0c (try 1/3)
[   33.592941] wlan0: authenticated
[   33.593649] wlan0: associate with c8:d7:19:ab:99:0c (try 1/3)
[   33.625099] wlan0: RX AssocResp from c8:d7:19:ab:99:0c (capab=0x411 status=0 aid=2)
[   33.625149] wlan0: associated
[   33.625159] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[bijju@bijju-myDesktop ~]$ dmesg | grep -i wlan
[    2.605150] usb 2-1.6: Product: 802.11n WLAN Adapter
[    8.338918] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   33.539501] wlan0: authenticate with c8:d7:19:ab:99:0c
[   33.550839] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[   33.563042] wlan0: send auth to c8:d7:19:ab:99:0c (try 1/3)
[   33.592941] wlan0: authenticated
[   33.593649] wlan0: associate with c8:d7:19:ab:99:0c (try 1/3)
[   33.625099] wlan0: RX AssocResp from c8:d7:19:ab:99:0c (capab=0x411 status=0 aid=2)
[   33.625149] wlan0: associated
[   33.625159] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[bijju@bijju-myDesktop ~]$ clear

[bijju@bijju-myDesktop ~]$ dmesg | grep -i wlan
[    2.605150] usb 2-1.6: Product: 802.11n WLAN Adapter
[    8.338918] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   33.539501] wlan0: authenticate with c8:d7:19:ab:99:0c
[   33.550839] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[   33.563042] wlan0: send auth to c8:d7:19:ab:99:0c (try 1/3)
[   33.592941] wlan0: authenticated
[   33.593649] wlan0: associate with c8:d7:19:ab:99:0c (try 1/3)
[   33.625099] wlan0: RX AssocResp from c8:d7:19:ab:99:0c (capab=0x411 status=0 aid=2)
[   33.625149] wlan0: associated
[   33.625159] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[bijju@bijju-myDesktop ~]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
From 192.168.1.112 icmp_seq=31 Destination Host Unreachable
From 192.168.1.112 icmp_seq=32 Destination Host Unreachable
From 192.168.1.112 icmp_seq=33 Destination Host Unreachable
From 192.168.1.112 icmp_seq=34 Destination Host Unreachable
From 192.168.1.112 icmp_seq=35 Destination Host Unreachable
From 192.168.1.112 icmp_seq=36 Destination Host Unreachable
From 192.168.1.112 icmp_seq=37 Destination Host Unreachable



Nothing happens then receiving, and tried to check the internet bandwidth speed when it connects (ie.,as soon as i login into the machine) [external host test]:
Download speeds:
With ASUS USB-N13 B1 (RTL8192cu): 3 to 5mbps sometime it goes to 7/8 then comes back to 0 (error)
Same location i used my laptop built in wifi: which goes 55mbps and it stays 
[i tried the usb in my laptop as well, same no change the way it works, both using F18 x86_64 - Kernel 3.8.5.201.fc18.x86_64].

I have pretty powerfully desktop but not able to use it.

Let me know if you need more specific info.

From what i observed is it keep disconnecting and when i see the network [GUI] shows as connecting....


Thanks
B
Comment 47 Bijju 2013-04-04 10:22:56 EDT
Hi All,

I understand that all you guys are working so hard to fix the issues.... but please can someone suggest me a better usb wireless which works out of the box with real speeds like N band with 300mbps with drivers please.. (on F18 x86_64 please) that will great help.. i can get new usb wireless. 

Thanks in advance. :)

Thanks
B
Comment 48 Larry Finger 2013-04-04 10:46:08 EDT
With all due respect, you are providing me with very little information regarding your problems. As it does not happen here, the problem has to be something different with your system, but what?
Comment 49 Bijju 2013-04-04 11:17:57 EDT
Larry

Sure not a problem, i can provide with more info, let me know what info i need to get, i mean like commands i need to use to get the info.

:)

Thanks
B
Comment 50 Leif Gruenwoldt 2013-04-04 11:28:49 EDT
The 3.8.5 kernel update did not fix the issue for me either -- the connection still drops within a few minutes. I'll try to gather some logs.
Comment 51 Leif Gruenwoldt 2013-04-04 22:42:46 EDT
This is repeated roughly a dozen times in dmesg:

[  352.585917] wlan0: authenticate with 00:1d:7e:f8:23:60
[  352.609860] wlan0: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[  352.623289] wlan0: send auth to 00:1d:7e:f8:23:60 (try 1/3)
[  352.639792] wlan0: authenticated
[  352.639965] rtl8192cu 5-1:1.0 wlan0: disabling HT/VHT due to WEP/TKIP use
[  352.639970] rtl8192cu 5-1:1.0 wlan0: disabling HT as WMM/QoS is not supported by the AP
[  352.639973] rtl8192cu 5-1:1.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP
[  352.640288] wlan0: associate with 00:1d:7e:f8:23:60 (try 1/3)
[  352.656728] wlan0: RX AssocResp from 00:1d:7e:f8:23:60 (capab=0x411 status=12 aid=0)
[  352.656733] wlan0: 00:1d:7e:f8:23:60 denied association (code=12)
[  352.663103] wlan0: deauthenticating from 00:1d:7e:f8:23:60 by local choice (reason=3)

$ uname -r
3.8.5-201.fc18.x86_64
Comment 52 Larry Finger 2013-04-04 23:53:44 EDT
Code 12 denial of association means the ESSID or WPA/WEP secret is wrong.

What front-end software are you using to control the wireless?
Comment 53 Leif Gruenwoldt 2013-04-05 10:18:44 EDT
(In reply to comment #52)
> What front-end software are you using to control the wireless?

I'm using the default Network Manager applet in GNOME Shell.
Comment 54 Leif Gruenwoldt 2013-04-05 11:28:40 EDT
(In reply to comment #52)
> Code 12 denial of association means the ESSID or WPA/WEP secret is wrong.

I'm pretty sure the proper ESSID and password is provided by Network Manager. Because it eventually connects. And then disconnects minutes later.

The hardware works fine on the same PC in Windows 7.
Comment 55 Larry Finger 2013-04-05 12:04:45 EDT
Yes, the ESSID and secret are correct, but I don't understand why they are changed. I have never seen that on my system. What are the details of your setup? Include AP make/model, firmware source and version. encryption type, etc.

A major revision of some of the underlying code in rtlwifi has just been accepted into wireless-next for inclusion in kernel 3.10. As soon as this appears in the compat-drivers release, I hope that you will be able to implement it.
Comment 56 Leif Gruenwoldt 2013-04-05 17:03:11 EDT
(In reply to comment #55)
> What are the details of your setup? 

Linksys WRT54GL
Mixed B+G
Tomato Firmware v1.19.1463
WPA Personal (PSK) + TKIP
Comment 57 Leif Gruenwoldt 2013-04-10 21:40:53 EDT
Created attachment 733950 [details]
grep NetworkManager /var/log/messages

This shows NetworkManager connecting to my AP, then seconds later disconnecting, then retrying a bunch, and then aborting.
Comment 58 Larry Finger 2013-04-10 22:48:14 EDT
The output of dmesg will show the reason it is disconnecting.
Comment 59 Leif Gruenwoldt 2013-04-10 23:25:29 EDT
(In reply to comment #58)
> The output of dmesg will show the reason it is disconnecting.

It's code=12 as seen in comment #51. Was hoping seeing the related NetworkManager log would be useful.
Comment 60 Christian 2013-05-31 01:35:53 EDT
Mhmmm ... I don't think this problem is gone.

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 looked into using Realtek's driver instead, but it doesn't compile at this point. So, I'd appreciate some feedback:

- How do I start to debug this? See below for a bunch of command output. Let me know what else you need.

- Has anyone gotten Realtek's official driver to work with a recent kernel? 

- I do have to wonder -- given the history of this driver, should I just get another stick and not bother?

Command output follows.

$ 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 61 John Greene 2013-06-27 09:53:13 EDT
(In reply to Christian from comment #60)
> Mhmmm ... I don't think this problem is gone.
> 
..
> 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.
> 
> 
> I looked into using Realtek's driver instead, but it doesn't compile at this
> point. So, I'd appreciate some feedback:
> 
> - How do I start to debug this? See below for a bunch of command output. Let
> me know what else you need.
> 
> - Has anyone gotten Realtek's official driver to work with a recent kernel? 
> 
> - I do have to wonder -- given the history of this driver, should I just get
> another stick and not bother?
> 

Christian,
I haven't worked directly with vendor driver, but a bunch lately with Realtek upstream driver.  I hope this might help you: I had similar issues with the USB devices: eerily so.  PCI-e devices were fine, USB devices were weird, inconsistent, flaky.  
You are on 3.9 kernel, the below patches (and others from v3.9 forward) from linus' tree seem to much improve the performance of USB RealTek USB..  They are in v3.10-rc2 kernel, suggest you try that if/when you can.  Let me know how you fare..


657e276 rtlwifi: usb: add NET_IP_ALIGN padding to RX skb when needed
29bb701 rtlwifi: usb: defer rx processing to tasklet
d7d0f08 rtlwifi: usb: remove extra skb copy on RX path
872de8f rtlwifi: usb: use usb_alloc_coherent for RX buffers
Comment 62 Larry Finger 2013-06-27 11:39:04 EDT
There are additional patches that do not make it into mainline until 3.10-rc6. I would suggest using 3.10-rc7.

5b8df24 rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1) networks
0446bfe rtlwifi: rtl8192cu: Fix false loss of AP indication
Comment 63 Christian 2013-07-01 04:23:09 EDT
Thanks for the pointers, guys ... I'm currently using Realtek's driver, which I got to compile with pretty little effort (see various patched trees on Github) and which works fine. I will report back once newer kernels fix the problems for me. Fingers crossed.
Comment 64 Christian 2013-08-17 18:53:32 EDT
Hi guys,

At this point 3.10.6 is standard in Fedora 18 and I'm sorry to report that nothing has changed whatsoever -- connectivity still locks up after a few minutes. I'm for now sticking to 3.9.6 because I have a working build of Realtek's driver, which continues to work okay. Needless to say, I don't think this ticket should be closed. :(

As before, if I can provide output that helps with debugging, I'll be more than happy to do so.

-C.
Comment 65 Larry Finger 2013-09-26 15:58:46 EDT
Created attachment 803560 [details]
Patch to improve automatic gain control

The existing automatic gain control for rtl8192cu fails in some setups. This patch improves the code quite a bit.
Comment 66 Josh Boyer 2013-09-26 16:10:48 EDT
(In reply to Larry Finger from comment #65)
> Created attachment 803560 [details]
> Patch to improve automatic gain control
> 
> The existing automatic gain control for rtl8192cu fails in some setups. This
> patch improves the code quite a bit.

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 67 Larry Finger 2013-09-26 17:50:41 EDT
No, the patch is OK. My trial patches are applied after that one and I had to include it. I should have removed that commit message, but it is OK.
Comment 68 Larry Finger 2013-09-26 17:57:35 EDT
Created attachment 803615 [details]
Patch to improve automatic gain control - revised

Updated version with misleading commit message removed.
Comment 69 Christian 2013-10-18 20:11:54 EDT
Are there any updates here regarding the failure-after-a-few-minutes problem? I still see bug reports this all over the place ... is gain control the suspected culprit for this problem?

Thanks,
-C.

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