Description of problem: I have ThinkPad E420 with rtl8188ce. After bringing up a wifi connection for about 20-30 seconds I have a decent speed of more then 10Mb/s which then drops to 1Mb/s. Switching wifi off then back on restores fast speed for another 20-30 seconds and then it drops back to 1Mb/s again. Reproducible on kernel-3.1.5-6.fc16.x86_64 and kernel-3.1.6-1.fc16.x86_64. Test have been performed near AP, so the connection is fine: [root@leopard ~]# iwconfig wlan0 wlan0 IEEE 802.11bgn ESSID:"Rivendell" Mode:Managed Frequency:2.412 GHz Access Point: 00:26:5A:51:4F:98 Bit Rate=54 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr=2347 B Fragment thr:off Encryption key:off Power Management:off Link Quality=64/70 Signal level=-46 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:10304 Missed beacon:0 Bit rate doesn't change from 54Mb/s. Speed does not depend on protocol, same behaviour for ftp, http, scp. Nearby laptop with Intel wifi with F16 works as expected. Version-Release number of selected component (if applicable): [root@leopard ~]# lspci | grep -i rtl 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) 08:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01) [root@leopard ~]# rpm -qa | grep linux-firmware linux-firmware-20110731-2.fc16.noarch [root@leopard ~]# uname -a Linux leopard 3.1.6-1.fc16.x86_64 #1 SMP Wed Dec 21 22:41:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Every time. Also there are a lot of similar reports over the Internet. Steps to Reproduce: 1. Turn on rtl8188ce wifi and start any download 2. Speed drops to 1Mb/s after 20-30 secs 3. Speed remains 1Mb/s until you turn off and then on wifi Actual results: Speed is around 1Mb/s Expected results: Speed > 10Mb/s Additional info:
Additional information: When I download something from this laptop with rtl8188ce and the speed is 1Mb/s other laptops on same WiFi network experience slow connection (around 1-1,5Mb/s). As soon as I stop download on rtl8188ce, other laptops gain speed instantly to 10Mb/s and over. Similar report here: http://ubuntuforums.org/showthread.php?t=1886838
Did you try to update firmware of your AP?
No, I did not. However, I have tried installing Windows 7 on this laptop and I don't experience described problem in Windows 7 -- the speed is >10Mb and quite stable. Make me think it's a driver issue, isn't it?
Absolute same thing with my Thinkpad x220 (it has rtl8188ce too).
I thought rtlwifi maintainers are CCed here, but apparently they were not, CCing now. Is this issue reproducible on fedora kernel 3.2.5 (which use wireless stack from 3.3-rc)?
I do not think using fedora kernel 3.2.5 will help. Unlike previous reports of this problem, today I was able to duplicate it running the current wireless-testing kernel. Running netperf, I got the following: TCP_MAERTS Test: 18.15 18.45 18.40 8.82 1.11 1.12 1.12 1.13 1.08 0.98 Results: max 18.45, min 0.98. Mean 7.04(7.73) TCP_STREAM Test: 5.91 5.88 5.67 5.91 6.02 3.05 6.26 6.15 6.48 6.18 Results: max 6.48, min 3.05. Mean 5.75(0.93) In addition, I was able to capture this sequence using kismet on a second computer. I now know that the slowdown occurs because the AP is having to retransmit every packet 3 or 4 times. At the 18 Mbps rate, every packet is ACKed immediately. Unfortunately, I don't know why rtl8192ce is not ACKing the packets..
At least ones - reproducible bug :-) If do not ack, we basically do not decode incoming frames, so this could be some phy chip programming issue at higher rates. If this is not a regression, this probably can only be fixed by Realtek/Realsil . BTW: I did not see any responses from chaoming_li for quite long time, perhaps our contact at Realtek/Reasil should be refreshed.
The problem exists in the latest vendor driver available from the Realtek web site - it is clearly not a regression. Yes, I need to find out what has happened to Chaoming.
Hi colleagues, Same issue here. I bought recently ASUS PCE-N15 which has the Realtek chip inside. My Fedora 16 (3.2.7-1.fc16.x86_64) chooses this driver: Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01) The connection starts at hight speed around 16 Mbit/s then after ~20-30 seconds it fails down to 1 Mbit/sec and remains at this level. Once this happens my old Asus WL500gP router gets occupied servicing this poor Fedora connection so all the other devices connected to it are almost dropped off.
When this condition occurs, the AP is having to retransmit every packet to the RTL8188CE 4 or 5 times, which is why the network gets overloaded. Realtek sent me a new version of the vendor driver that is supposed to fix the problem. I have built that driver. It works fine with the RTL8192CE and I am now testing with the RTL8188CE. Thus far, it has not failed after 15 minutes, which is longer that ever before. Once I port their changes to the kernel driver nad tested once again, I will post a trial patch here.
The essence of Realtek's change turned out to be 3 lines. I implemented those new lines and started testing with the RTL8188CE card. So far, it has been running for 50 minutes without slowing. The patch will be in my next posting. Please test and report.
Created attachment 566412 [details] Trial patch to fix slow down of RTL8188CE
I lunched kernel build with Larry's patch here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3839463
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.
I upgraded and tested for a while. Confirm - all works perfect now. Thank you very much!
(In reply to comment #17) > I upgraded and tested for a while. Confirm - all works perfect now. Ah no, after about 1 hour I faced the same performance reducing - back to 1 mbit (from 16 mbit). will continue checking what's going on.
Created attachment 572586 [details] Second patch to fix rtl8192ce slow-down I added some test code to the driver and found that when the slowdown was occurring, the initial gain was being set to a low value. By averaging the previous 16 values, and refusing to change the gain if the new value was too small, I got rid of the slowdowns. Next I did a stack dump when the low gain was posted, and found that the condition was initiated by a start when the scan started. By changing that value from 0x17 to 0x237, I was able to stop the slowing. As I write this, the driver has been running correctly for about 3 hours.
(In reply to comment #19) > Created attachment 572586 [details] > Second patch to fix rtl8192ce slow-down > > I added some test code to the driver and found that when the slowdown was > occurring, the initial gain was being set to a low value. By averaging the > previous 16 values, and refusing to change the gain if the new value was too > small, I got rid of the slowdowns. Next I did a stack dump when the low gain > was posted, and found that the condition was initiated by a start when the scan > started. By changing that value from 0x17 to 0x237, I was able to stop the > slowing. > > As I write this, the driver has been running correctly for about 3 hours. Tried both patches but after 7-10 hours slowdown is occurring again not so much as before. Right after booting OS is around 35-40Mb, then after 7-10 hours 13Mb.
Based on the report of the OP, I have been testing only with an 802.11g connection. Mine started at an RX rate of 18 Mbps and after 30+ hours of testing, the rate was still at 18. From the rates you quote, you obviously have an 802.11n connection. What is the maximum rate of the AP? I will test again on an 802.11n connection that goes "up to 270 Mbps".
iw wlan0 station dump shows iw wlan0 station dump Station xx:xx:xx:xx:xx:xx (on wlan0) inactive time: 2315 ms rx bytes: 22336 rx packets: 169 tx bytes: 31411 tx packets: 106 tx retries: 0 tx failed: 0 signal: -43 dBm signal avg: -43 dBm tx bitrate: 144.4 MBit/s MCS 15 short GI authorized: yes authenticated: yes preamble: short WMM/WME: yes MFP: no TDLS peer: no now I have only smartphone with 802.11n wifi module which shows 72Mbps. Tried downloading file from computer and it shows maximum 42Mbps but it's because of limited sd-card writing speed, also tried speedtest which shows 45-50Mbps(I have 50Mbps internet channel), in both cases after a few hours speed does not exceed 13Mbps.
I'm sorry but forgot to mention that I'm using rtl8188ce as AP via hostapd, before your patches it slows down for a couple of minutes to 0.8Mb. And also I have problems with random signal disappearing when AP just stop receiving packets, sometimes restarting hostapd helps but not always.
I have only tested using RTL8188CE in station mode. So far, it just seems to work. One thing that confuses me about your station dump, which shows MCS 15. I thought that was for dual-stream 20 MHz setup. I get the expected MCS 7, which means a single stream at 40 GHz. As the original complaint is for station mode and 802.11g, I think you should open a new bug report for AP mode and 802.11n. BTW, the first patch is in kernel 3.3-git, and the second was sent upstream today. It will likely be in 3.4-rc1 or -rc2.
It's still no luck here - with the latest kernel (Linux mizar 3.3.5-2.fc16.x86_64 #1 SMP Tue May 8 11:24:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux) the behaviour is still the same.
Thinkpad edge, Fedora 17, last kernel x86_64, connecting to the wireless router is fast and durable, but the data transfer is interrupted after 20 seconds.
Also Fedora 17, x86_64, connecting to a 802.11b/g/n router, in n mode, also slows after not long, please let me know if i can provede any logs etc.
Exactly the same issue here on a Thinkpad T410 with Intel wifi, Fedora 17. After 2~3 minutes the connection drops down to 1mb/s. Other machines (one MacBook, one iPad, Android phones) works in the same access point without a problem. ffranz@ffranz ~$ iwconfig wlan0 wlan0 IEEE 802.11abgn ESSID:"PriBi Hell Yeah" Mode:Managed Frequency:2.412 GHz Access Point: B0:48:7A:A2:B6:BC Bit Rate=52 Mb/s Tx-Power=0 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=52/70 Signal level=-58 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:2140 Invalid misc:275 Missed beacon:0 ffranz@ffranz ~$ lspci | grep Network 00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 06) 03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35) ffranz@ffranz ~$ uname -a Linux ffranz 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Please let me know if you need any additional info, thanks.
Note the Bit Rate now: ffranz@ffranz ~$ iwconfig wlan0 wlan0 IEEE 802.11abgn ESSID:"PriBi Hell Yeah" Mode:Managed Frequency:2.412 GHz Access Point: B0:48:7A:A2:B6:BC Bit Rate=1 Mb/s Tx-Power=0 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=55/70 Signal level=-55 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:2213 Invalid misc:301 Missed beacon:0 (In reply to comment #28) > Exactly the same issue here on a Thinkpad T410 with Intel wifi, Fedora 17. > After 2~3 minutes the connection drops down to 1mb/s. Other machines (one > MacBook, one iPad, Android phones) works in the same access point without a > problem. > > ffranz@ffranz ~$ iwconfig wlan0 > wlan0 IEEE 802.11abgn ESSID:"PriBi Hell Yeah" > Mode:Managed Frequency:2.412 GHz Access Point: B0:48:7A:A2:B6:BC > > Bit Rate=52 Mb/s Tx-Power=0 dBm > Retry long limit:7 RTS thr:off Fragment thr:off > Power Management:off > Link Quality=52/70 Signal level=-58 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:2140 Invalid misc:275 Missed beacon:0 > > ffranz@ffranz ~$ lspci | grep Network > 00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network > Connection (rev 06) > 03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev > 35) > > ffranz@ffranz ~$ uname -a > Linux ffranz 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 > x86_64 x86_64 GNU/Linux > > Please let me know if you need any additional info, thanks.
Hello Everyone, I have an RTL8188CE chip in my Toshiba C670D, and like everyone else I get continuous drop out of connectively. It works fine on windows, and it worked on the previous fedora 16 with 32bit. The current 64bit system I am using is no go. It also from test seems to work find on Ubuntu but I didn't test for very long as I am not a Ubuntu fan. 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01) I realize there is not a lot of information providied by me so if anyone can tell me what info you need and info on how to get it to have the best shot of killing this damned issue I would be greatful and will try and supply. Also my output from lsmod shows that it has module rtl8192ce loaded but rtl8188ce is no where in the list is this normal. I am not guru but can compile code, so seriously if anyone has any tests they want me to try, please let me know. I do not want to have to switch to another distro just because an rtl8188ce ship doesn't work.
Not everyone else has dropouts with the RTL8188CE. I have been using mine exclusively for the past 4 weeks as a long-term test. During that time, I have had only one dropout. I have been running openSUSE 12.1 and 12.2 Beta1 (64-bit version) with it and using a kernel from wireless-testing. The speed drop to 1 Mbps on an 802.11g link was fixed quite some time ago. For me, it never happened on my 802.11n router. Both the RTL8192CE and the RTL8188CE use driver rtl8192ce - that is normal. There is no driver rtl8188ce! I have no idea why you are having a problem. If I could duplicate it, I could probably fix it, but with little details, there is little I can do. It is not a 32- versus 64-bit problem. My only suggestion is that you try implementing the latest bleeding-edge compat-wireless code. That way you will be using the same code as I am. I am not aware of any changes in the driver or the wireless stack that could have caused a problem when you went from Fedora 16 to 17.
Hello Larry, Thanks for the quick response. I would prefer to stick with Fedora if at all possible, the compat-wireless code you mention is this the right place to get that code: http://linuxwireless.org/en/users/Download#Compat-wireless_release_types Since don't really know a lot regarding the information needed to properly report problems with wireless code is there any specific sets of information you would need to see. I tried compiling the realtek drivers off their official website but since I am running a Fedora 17 Latest kernel their source doesn't compile. If I switch back 32 bit fedora build temporarily and the problem goes away what would I need to report to realtek / redhat/ you ect. Also since from what you said it sounds like I am having a diferent issue, should I report this in some other place on bugzilla, or can it be moved to some place more appropriate. Thankyou Terry Wallwork
That link is OK as long as you go to the "bleeding-edge" section. The correct URL is http://linuxwireless.org/download/compat-wireless-2.6/compat-wireless-2.6.tar.bz2. Realtek drivers frequently do not compile on the latest kernels. Initially, I was feeding patches back to them, but when they never used them, I stopped. To report the most useful information, you need to post any logging found in the dmesg output. That way we will know the reason for the disconnection. It may be that your AP is not as forgiving as all 3 of mine. If a 32-bit version of Fedora 17 works, and 64-bit fails, that should definitely be reported here.
Created attachment 915466 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Created attachment 915467 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Hi Larry, The one difference I notice between the 32Bit version and the 64 bit version is the output of: iwlist wlan0 scanning In the 32Bit version only 1 cell seems to show up (the other wiress networks are listed in NetworkManager though) [terry@localhost log]$ iwlist wlan0 scanning wlan0 Scan completed : Cell 01 - Address: 00:FE:F4:3E:7E:30 Channel:6 Frequency:2.437 GHz (Channel 6) Quality=60/70 Signal level=-50 dBm Encryption key:on ESSID:"TWNetwork" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf=00000000ac4bd180 Extra: Last beacon: 9739507ms ago IE: Unknown: 000954574E6574776F726B IE: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011BFFFF000000000000000000000000000000000000000000 IE: Unknown: 3D1606001300000000000000000000000000000000000000 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: DD180050F20201018F0003A4000027A4000042435E0062322F00 IE: Unknown: DD1E00904C33AC011BFFFF000000000000000000000000000000000000000000 IE: Unknown: DD1A00904C3406001300000000000000000000000000000000000000 IE: Unknown: DD0900037F01010000FF7F In the 64bit version 3 cells gets listed: iwlist wlan0 scanning outputs: [root@localhost terry]# iwlist wlan0 scanning wlan0 Scan completed : Cell 01 - Address: 00:FE:F4:3E:7E:30 Channel:6 Frequency:2.437 GHz (Channel 6) Quality=57/70 Signal level=-53 dBm Encryption key:on ESSID:"TWNetwork" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf=00000006ccdfa168 Extra: Last beacon: 81ms ago IE: Unknown: 000954574E6574776F726B IE: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 2A0100 IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011BFFFF000000000000000000000000000000000000000000 IE: Unknown: 3D1606080000000000000000000000000000000000000000 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (2) : CCMP TKIP Authentication Suites (1) : PSK IE: Unknown: DD180050F20201018F0003A4000027A4000042435E0062322F00 IE: Unknown: DD1E00904C33AC011BFFFF000000000000000000000000000000000000000000 IE: Unknown: DD1A00904C3406080000000000000000000000000000000000000000 IE: Unknown: DD0900037F01010000FF7F Cell 02 - Address: 12:FE:F4:3E:7E:30 Channel:6 Frequency:2.437 GHz (Channel 6) Quality=57/70 Signal level=-53 dBm Encryption key:off ESSID:"BTFON" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf=00000006ccde8180 Extra: Last beacon: 630ms ago IE: Unknown: 00054254464F4E IE: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 050402030000 IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011BFFFF000000000000000000000000000000000000000000 IE: Unknown: 3D1606080000000000000000000000000000000000000000 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F20201018D0003A4000027A4000042435E0062322F00 IE: Unknown: DD1E00904C33AC011BFFFF000000000000000000000000000000000000000000 IE: Unknown: DD1A00904C3406080000000000000000000000000000000000000000 Cell 03 - Address: 02:FE:F4:3E:7E:30 Channel:6 Frequency:2.437 GHz (Channel 6) Quality=57/70 Signal level=-53 dBm Encryption key:off ESSID:"BTOpenzone-H" Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s 9 Mb/s; 12 Mb/s; 18 Mb/s Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s Mode:Master Extra:tsf=00000006ccdfad80 Extra: Last beacon: 605ms ago IE: Unknown: 000C42544F70656E7A6F6E652D48 IE: Unknown: 010882848B960C121824 IE: Unknown: 030106 IE: Unknown: 050400030000 IE: Unknown: 2A0100 IE: Unknown: 32043048606C IE: Unknown: 2D1AAC011BFFFF000000000000000000000000000000000000000000 IE: Unknown: 3D1606080000000000000000000000000000000000000000 IE: Unknown: 4A0E14000A002C01C800140005001900 IE: Unknown: 7F0101 IE: Unknown: DD180050F20201018F0003A4000027A4000042435E0062322F00 IE: Unknown: DD1E00904C33AC011BFFFF000000000000000000000000000000000000000000 IE: Unknown: DD1A00904C3406080000000000000000000000000000000000000000 I don't know what this means but its the only difference i can see. Hope this is some use. Terry Wallwork
I do not understand why the 64-bit version only shows 1 AP in the scan, while the 32-bit one shows 3. All of them are strong. I am quite sure that the dropouts with the 64-bit system are not the result of rtl8192ce. First of all, the 64-bit version works fine here - I never use a 32-bit variety. Secondly, the deauthentication is due to reason 6, which is "Class 2 frame received from nonauthenticated station". Driver rtl8192ce does not originate frames, it just sends them along. If the problem is in the kernel, it could be in the mac80211 stack. The 64-bit kernel is 'Linux version 3.4.0-1.fc17.x86_64". Is the 32-bit one also 3.4.0-1? Perhaps a Fedora Expert would know what other changes might be involved. The other possibility is that there are differences in the NetworkManager codes, or in whatever means you use to control wireless.
Hi Larry, The 64Bit Kernel is: uname -a Linux localhost.localdomain 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux The 32Bit Kernel was: uname -a Linux localhost.localdomain 3.3.4-5.fc17.i686 #1 SMP Mon May 7 17:45:26 UTC 2012 i686 i686 i386 GNU/Linux So I manually updated the 32 bit kernel to the same version kernal 3.4.0-1. So now the 32Bit Kernel is: Linux localhost.localdomain 3.4.0-1.fc17.i686 #1 SMP Sun Jun 3 07:16:04 UTC 2012 i686 i686 i386 GNU/Linux Same result though 32bit kernel can only see one cell, and its still rock solid, while 64bit is flaky and can see all 3 cells. On the other issue of weather this is the RTL8188CE problems or the mac80211 stack, yes please understand I know nothing about wireless, I just latched onto RTL8188CE as a way to describe the wireless adapter that I can't get to work reliably. I am not assigning blame to the driver :) So is there anyway to make the wifi system ignore the other cell signals like it does with 32 for the 64 bit version. Is there any more information I can try and supply that can narrow this down any further. Thanks Terry Wallwork
And yes just to be clear I use Fedora 17's Network Manager through, no hacks or things like wicd etc. If there is a way to bypass networkmanager and replicate my about configuration manually, I would try it, if someone explains the command to do it manually. Terry Wallwork
about should have been above
Hi All Iv found out a few things with regards this problem, when trouble shooting a wifi usb card, on another fedora 17 machine, wifi card using winxp drivers via ndiswrapper, and when trying to connect the my router, i had the same problem, both machines f17 64, different wifi cards, same problem. I did find however, that both pc's worked fine with the router turned from ng mode to n mode only, connecting at 177mb/s +, and its been running for a few hours now with no issues. Maybe someone else can try the same thing and confirm the result? PS. Thank you to all involved in the creation of and awesome OS!
It appears that you have a problem with your access point, and that this thread can be closed.
Well, after more testing my problems arnt fully resolved still :/ but that seemed to have helped, but i did not start this thread, so dont think it should be closed just yet.
Both patches from this bugzilla are now applied to 3.4 . They fix problem originally reported here, which Larry was capable to reproduce. Thanks Larry! Closing. If someone have still performance problems with RTL8188CE need to open separate bug report.