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:
Created attachment 561118 [details] /var/log/messages
Created attachment 561119 [details] dmesg
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
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.
$ 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
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?
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/
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.
(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.
Anyone know where Fedora logs the NetworkManager data?
(In reply to comment #10) > Anyone know where Fedora logs the NetworkManager data? It just logs to /var/log/messages
Thanks for the info.
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
*** Bug 806142 has been marked as a duplicate of this bug. ***
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.
This issue still happens in kernel-3.3.1-3.fc17.x86_64. When does this patch apply to kernel package?
(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.
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.
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.
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
Created attachment 576640 [details] When wireless usb land card can't connect internet, /var/log/messages in $ifdown wlan0
Created attachment 576642 [details] While executing $ ifup wlan0, /var/log/messages.
This bug still happens in 3.3.4-5.fc17.x86_64.
Still happens in 3.4.4-5.fc17.x86_64
Larry, any further thoughts on this one?
# 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).
Open new bug 869870
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
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
This bug still happens in fedora 18. kernel-3.7.2-201.fc18.x86_64
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.
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.
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
Missing Kernel Info: 3.8.4-202.fc18.x86_64 Thanks B
This problem should be fixed in kernel 3.9-rc4.
The fix is now in 3.8.5.
(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.
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
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).
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.
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.*.
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.
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
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
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.
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
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
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?
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
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.
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
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?
(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.
(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.
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.
(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
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.
The output of dmesg will show the reason it is disconnecting.
(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.
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)
(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
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
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.
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.
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.
(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> 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> Did you perhaps attach the wrong patch?
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.
Created attachment 803615 [details] Patch to improve automatic gain control - revised Updated version with misleading commit message removed.
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.