Bug 770207 - Realtek rtl8188ce works slow: speed is around 1Mb/s
Summary: Realtek rtl8188ce works slow: speed is around 1Mb/s
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-24 10:15 UTC by Ivan Pesin
Modified: 2012-07-25 09:51 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-25 09:51:19 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Trial patch to fix slow down of RTL8188CE (697 bytes, patch)
2012-02-28 23:16 UTC, Larry Finger
no flags Details | Diff
Second patch to fix rtl8192ce slow-down (593 bytes, patch)
2012-03-25 22:17 UTC, Larry Finger
no flags Details | Diff
Comment (77.05 KB, text/plain)
2012-06-17 12:07 UTC, Terry Wallwork
no flags Details
Comment (90.48 KB, text/plain)
2012-06-17 16:35 UTC, Terry Wallwork
no flags Details

Description Ivan Pesin 2011-12-24 10:15:33 UTC
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:

Comment 1 Ivan Pesin 2011-12-24 13:48:10 UTC
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

Comment 2 Stanislaw Gruszka 2011-12-31 11:32:50 UTC
Did you try to update firmware of your AP?

Comment 3 Ivan Pesin 2012-01-01 12:37:49 UTC
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?

Comment 4 Alexander Maslov 2012-02-16 09:43:42 UTC
Absolute same thing with my Thinkpad x220 (it has rtl8188ce too).

Comment 5 Stanislaw Gruszka 2012-02-16 10:40:33 UTC
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)?

Comment 6 Larry Finger 2012-02-16 17:43:02 UTC
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..

Comment 7 Stanislaw Gruszka 2012-02-17 11:50:59 UTC
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.

Comment 8 Larry Finger 2012-02-17 13:42:31 UTC
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.

Comment 9 Eugene 2012-02-28 21:05:59 UTC
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.

Comment 10 Larry Finger 2012-02-28 21:56:58 UTC
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.

Comment 11 Larry Finger 2012-02-28 23:14:05 UTC
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.

Comment 12 Larry Finger 2012-02-28 23:16:35 UTC
Created attachment 566412 [details]
Trial patch to fix slow down of RTL8188CE

Comment 13 Stanislaw Gruszka 2012-02-29 10:06:17 UTC
I lunched kernel build with Larry's patch here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3839463

Comment 14 Dave Jones 2012-03-22 16:50:54 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 15 Dave Jones 2012-03-22 16:55:05 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 16 Dave Jones 2012-03-22 17:05:53 UTC
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Comment 17 Eugene 2012-03-22 20:18:04 UTC
I upgraded and tested for a while. Confirm - all works perfect now. Thank you very much!

Comment 18 Eugene 2012-03-22 20:46:15 UTC
(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.

Comment 19 Larry Finger 2012-03-25 22:17:09 UTC
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.

Comment 20 Ivan Ivanovich 2012-03-27 16:42:43 UTC
(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.

Comment 21 Larry Finger 2012-03-27 17:08:02 UTC
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".

Comment 22 Ivan Ivanovich 2012-03-27 17:25:07 UTC
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.

Comment 23 Ivan Ivanovich 2012-03-27 19:45:14 UTC
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.

Comment 24 Larry Finger 2012-03-27 20:04:39 UTC
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.

Comment 25 Eugene 2012-05-15 17:59:58 UTC
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.

Comment 26 Frederic 2012-05-30 08:41:39 UTC
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.

Comment 27 Daniel Williams 2012-06-06 08:58:44 UTC
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.

Comment 28 Fabiano Franz 2012-06-12 14:32:02 UTC
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.

Comment 29 Fabiano Franz 2012-06-12 14:34:45 UTC
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.

Comment 30 Terry Wallwork 2012-06-16 11:20:11 UTC
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.

Comment 31 Larry Finger 2012-06-16 13:59:40 UTC
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.

Comment 32 Terry Wallwork 2012-06-16 18:57:00 UTC
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

Comment 33 Larry Finger 2012-06-16 20:46:55 UTC
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.

Comment 34 Terry Wallwork 2012-06-17 12:07:46 UTC
Created attachment 915466 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

Comment 35 Terry Wallwork 2012-06-17 16:35:46 UTC
Created attachment 915467 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

Comment 36 Terry Wallwork 2012-06-17 16:45:06 UTC
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

Comment 37 Larry Finger 2012-06-17 17:10:15 UTC
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.

Comment 38 Terry Wallwork 2012-06-17 18:30:00 UTC
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

Comment 39 Terry Wallwork 2012-06-17 18:32:31 UTC
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

Comment 40 Terry Wallwork 2012-06-17 18:34:09 UTC
about should have been above

Comment 41 Daniel Williams 2012-07-24 11:50:13 UTC
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!

Comment 42 Larry Finger 2012-07-24 15:11:54 UTC
It appears that you have a problem with your access point, and that this thread can be closed.

Comment 43 Daniel Williams 2012-07-24 16:03:41 UTC
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.

Comment 44 Stanislaw Gruszka 2012-07-25 09:51:19 UTC
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.


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