(Resending original message because Text/HTML content was rejected)
Hi,
I am trying to use the Linux kernel driver for the RTL8723E wifi card.
While the card works flawlessly in Windows, it is unusable under Linux. For
low-signal APs, such as in public places, the kernel continuously drops the
AP connection and reconnects. This brings the transfer rate almost to a
stop. I compiled the sources of the unofficial kernel driver distributed by
Realtek to get this card working.
My question to you: is there a threshold parameter in the driver source
code that I can play with to stop the driver from dropping AP connections
even though the signal is low?
I would really appreciate any suggestions as this problem is rendering the
wifi card unusable.
Here are my system specifics:
# uname -a
Linux cenlap 3.4-trunk-amd64 #1 SMP Tue Jun 26 17:23:03 UTC 2012 x86_64
GNU/Linux
It's a Debian (Testing level). From dmesg:
Linux version 3.4-trunk-amd64 (Debian 3.4.4-1~experimental.1) (
[email protected]) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1
SMP Tue Jun 26 17:23:03 UTC 2012
# lspci -v -s 03:00.0
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8723
Subsystem: Realtek Semiconductor Co., Ltd. Device 0726
Flags: bus master, fast devsel, latency 0, IRQ 18
I/O ports at d000 [size=256]
Memory at f7900000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-23-87-fe-ff-4c-e0-00
Kernel driver in use: rtl8723e
Using driver rtl_92ce_92se_92de_8723ae_
linux_mac80211_0006.0514.2012
I did have to comment out IEEE80211_HW_BEACON_FILTER (line 320 in base.c)
to be able to compile your kernel driver for my 3.4 kernel, following the
description here:
http://askubuntu.com/questions/139632/wireless-card-realtek-rtl8723ae-bt-is-not-recognized
Here are the errors I'm getting on dmesg and I can see WPA_GUI continuously
reconnecting every few seconds:
[ 7316.486880] wlan0: Connection to AP 00:0a:06:05:01:53 lost.
[ 7316.487711] cfg80211: Calling CRDA to update world regulatory domain
[ 7317.519557] wlan0: authenticate with 00:0a:06:05:01:53
[ 7317.551189] wlan0: send auth to 00:0a:06:05:01:53 (try 1/3)
[ 7317.754273] wlan0: send auth to 00:0a:06:05:01:53 (try 2/3)
[ 7317.958152] wlan0: send auth to 00:0a:06:05:01:53 (try 3/3)
[ 7318.162085] wlan0: authentication with 00:0a:06:05:01:53 timed out
[ 7329.506332] wlan0: authenticate with 00:0a:06:05:01:97
[ 7329.519585] wlan0: send auth to 00:0a:06:05:01:97 (try 1/3)
[ 7329.521128] wlan0: authenticated
[ 7329.536739] wlan0: associate with 00:0a:06:05:01:97 (try 1/3)
[ 7329.538853] wlan0: RX AssocResp from 00:0a:06:05:01:97 (capab=0x421
status=0 aid=1)
[ 7329.538858] wlan0: associated
[ 7332.527325] wlan0: Connection to AP 00:0a:06:05:01:97 lost.
[ 7332.531547] cfg80211: Calling CRDA for country: US
Thanks,
Cengiz
Hi,
Thanks for responding, Larry.
On Fri, Nov 30, 2012 at 3:52 PM, Larry Finger <[email protected]> wrote:
> On 11/30/2012 04:19 PM, Cengiz Günay wrote:
>> I did have to comment out IEEE80211_HW_BEACON_FILTER (line 320 in base.c)
>> to be able to compile your kernel driver for my 3.4 kernel, following the
>> description here:
>>
>> http://askubuntu.com/questions/139632/wireless-card-realtek-rtl8723ae-bt-is-not-recognized
>>
>
> That is a matter of the vendor driver. I deal with that driver only in that
> I use it as a starting point for the version built into the Linux kernel.
> Any build problems were fixed several months ago.
Oh, great! I didn't even know there was a newer driver. I should've
checked linux-wireless again.
> The first thing I request is that you try the version that will be added to
> kernel version 3.8 as it is the one I specifically support. It is currently
> available in the 3.7-rc7 versions of the linux-next, wireless-next, and
> wireless-testing git trees.
Ok, I will try this.
> The second thing is to report the signal strength at which the device fails.
Here's an example of the signal strength:
# iwconfig wlan0
wlan0 IEEE 802.11bgn ESSID:**SD-HOTEL-AP** [snip]
Mode:Managed Frequency:2.437 GHz Access Point: 00:[snip]
Bit Rate=18 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=42/70 Signal level=-68 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:7 Missed beacon:0
This is particularly strong, but I have seen the link quality at 22/70
and signal at -88 dBm mostly.
> On my system, the driver runs without disconnection for days at a time;
> however, the signals are quite strong from my APs. Once I know where the
> difficulty happens, I can attenuate the signal.
Yes, I agree the driver works fine with high signal power as I use
this laptop at home without any problems. But it has consistently
failed in public places. There is a similar complaint in the Ubuntu
discussion page as well.
> Have you tried changing the power settings using the module parameters. I do
> not know what those are in the vendor driver, but in the kernel version, the
> pertiment ones are:
>
> parm: ips:Set to 0 to not use link power save (default 1)
> parm: swlps:Set to 1 to use SW control power save (default 0)
> parm: fwlps:Set to 1 to use FW control power save (default 1)
>
> My suggestion is to disable link power saving with the "ips=0" option, or
> whatever the vendor driver uses.
Here's the vendor's parameters:
# modinfo rtl8723e
parm: swlps:bool
parm: swenc:using hardware crypto (default 0 [hardware]) (bool)
parm: ips:using no link power save (default 1 is open) (bool)
parm: fwlps:using linked fw control power save (default 1 is open) (bool)
I tried setting ips=0
# modprobe -v rtl8723e ips=0
insmod /lib/modules/3.4-trunk-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723e/rtl8723e.ko
ips=0
I still see drops, but I feel the connections is much more stable (I
was able to see a youtube video without interruption somehow):
# dmesg | grep lost | tail -5
[ 2945.567620] wlan0: Connection to AP [snip] lost.
[ 2949.565782] wlan0: Connection to AP [snip] lost.
[ 2954.555432] wlan0: Connection to AP [snip] lost.
[ 2972.499182] wlan0: Connection to AP [snip] lost.
[ 3156.474054] wlan0: Connection to AP [snip] lost.
Thanks,
-Cengiz
On Sat, Dec 1, 2012 at 7:07 AM, Cengiz Günay > I tried setting ips=0
> # modprobe -v rtl8723e ips=0
> insmod /lib/modules/3.4-trunk-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8723e/rtl8723e.ko
> ips=0
>
> I still see drops, but I feel the connections is much more stable (I
> was able to see a youtube video without interruption somehow):
> # dmesg | grep lost | tail -5
> [ 2945.567620] wlan0: Connection to AP [snip] lost.
> [ 2949.565782] wlan0: Connection to AP [snip] lost.
> [ 2954.555432] wlan0: Connection to AP [snip] lost.
> [ 2972.499182] wlan0: Connection to AP [snip] lost.
> [ 3156.474054] wlan0: Connection to AP [snip] lost.
To quantify the "feeling of improvement", I calculated MTBF before and after:
Before setting ips=0:
# dmesg | grep lost | head -20 | awk 'BEGIN{printf "tf = [ "} {printf
$1 $2 " "} END{print "]; tbfs = diff(tf); mtbf=mean(tbfs),
stdbf=std(tbfs)"}' | octave -q
mtbf = 20.044
stdbf = 10.249
After setting ips=0:
# dmesg | grep lost | tail -20 | awk 'BEGIN{printf "tf = [ "} {printf
$1 $2 " "} END{print "]; tbfs = diff(tf); mtbf=mean(tbfs),
stdbf=std(tbfs)"}' | octave -q
mtbf = 65.917
stdbf = 43.618
There is definitely an improvement in MTBF from 20 to 65 s!
-Cengiz
On 11/30/2012 04:19 PM, Cengiz Günay wrote:
> Hi,
>
> I am trying to use the Linux kernel driver for the RTL8723E wifi card. While the
> card works flawlessly in Windows, it is unusable under Linux. For low-signal
> APs, such as in public places, the kernel continuously drops the AP connection
> and reconnects. This brings the transfer rate almost to a stop. I compiled the
> sources of the unofficial kernel driver distributed by Realtek to get this card
> working.
>
> My question to you: is there a threshold parameter in the driver source code
> that I can play with to stop the driver from dropping AP connections even though
> the signal is low?
>
> I would really appreciate any suggestions as this problem is rendering the wifi
> card unusable.
Although I am listed as a driver author, my efforts are limited to the specific
operations used in Linux. I have no knowledge of the operation of the chips and
no knowledge of the programming of the chips.
It sounds to me as if the automatic gain control is not being handled correctly.
>
> Here are my system specifics:
>
> # uname -a
> Linux cenlap 3.4-trunk-amd64 #1 SMP Tue Jun 26 17:23:03 UTC 2012 x86_64 GNU/Linux
>
> It's a Debian (Testing level). From dmesg:
> Linux version 3.4-trunk-amd64 (Debian 3.4.4-1~experimental.1)
> ([email protected] <mailto:[email protected]>) (gcc
> version 4.6.3 (Debian 4.6.3-1) ) #1 SMP Tue Jun 26 17:23:03 UTC 2012
>
> # lspci -v -s 03:00.0
> 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device 8723
> Subsystem: Realtek Semiconductor Co., Ltd. Device 0726
> Flags: bus master, fast devsel, latency 0, IRQ 18
> I/O ports at d000 [size=256]
> Memory at f7900000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 01-23-87-fe-ff-4c-e0-00
> Kernel driver in use: rtl8723e
>
> Using driver rtl_92ce_92se_92de_8723ae_
> linux_mac80211_0006.0514.2012
>
> I did have to comment out IEEE80211_HW_BEACON_FILTER (line 320 in base.c) to be
> able to compile your kernel driver for my 3.4 kernel, following the description
> here:
> http://askubuntu.com/questions/139632/wireless-card-realtek-rtl8723ae-bt-is-not-recognized
>
That is a matter of the vendor driver. I deal with that driver only in that I
use it as a starting point for the version built into the Linux kernel. Any
build problems were fixed several months ago.
> Here are the errors I'm getting on dmesg and I can see WPA_GUI continuously
> reconnecting every few seconds:
> [ 7316.486880 <tel:%5B%207316.486880>] wlan0: Connection to AP 00:0a:06:05:01:53
> lost.
> [ 7316.487711 <tel:%5B%207316.487711>] cfg80211: Calling CRDA to update world
> regulatory domain
> [ 7317.519557 <tel:%5B%207317.519557>] wlan0: authenticate with 00:0a:06:05:01:53
> [ 7317.551189 <tel:%5B%207317.551189>] wlan0: send auth to 00:0a:06:05:01:53
> (try 1/3)
> [ 7317.754273 <tel:%5B%207317.754273>] wlan0: send auth to 00:0a:06:05:01:53
> (try 2/3)
> [ 7317.958152 <tel:%5B%207317.958152>] wlan0: send auth to 00:0a:06:05:01:53
> (try 3/3)
> [ 7318.162085 <tel:%5B%207318.162085>] wlan0: authentication with
> 00:0a:06:05:01:53 timed out
> [ 7329.506332 <tel:%5B%207329.506332>] wlan0: authenticate with 00:0a:06:05:01:97
> [ 7329.519585 <tel:%5B%207329.519585>] wlan0: send auth to 00:0a:06:05:01:97
> (try 1/3)
> [ 7329.521128 <tel:%5B%207329.521128>] wlan0: authenticated
> [ 7329.536739 <tel:%5B%207329.536739>] wlan0: associate with 00:0a:06:05:01:97
> (try 1/3)
> [ 7329.538853 <tel:%5B%207329.538853>] wlan0: RX AssocResp from
> 00:0a:06:05:01:97 (capab=0x421 status=0 aid=1)
> [ 7329.538858] wlan0: associated
> [ 7332.527325] wlan0: Connection to AP 00:0a:06:05:01:97 lost.
> [ 7332.531547] cfg80211: Calling CRDA for country: US
The first thing I request is that you try the version that will be added to
kernel version 3.8 as it is the one I specifically support. It is currently
available in the 3.7-rc7 versions of the linux-next, wireless-next, and
wireless-testing git trees.
The second thing is to report the signal strength at which the device fails. On
my system, the driver runs without disconnection for days at a time; however,
the signals are quite strong from my APs. Once I know where the difficulty
happens, I can attenuate the signal.
Have you tried changing the power settings using the module parameters. I do not
know what those are in the vendor driver, but in the kernel version, the
pertiment ones are:
parm: ips:Set to 0 to not use link power save (default 1)
parm: swlps:Set to 1 to use SW control power save (default 0)
parm: fwlps:Set to 1 to use FW control power save (default 1)
My suggestion is to disable link power saving with the "ips=0" option, or
whatever the vendor driver uses.
Larry