Bug 12588

Summary: "weak signal" with rtl8180 and Belking 701f
Product: Drivers Reporter: drkludge
Component: network-wirelessAssignee: John W. Linville (linville)
Status: CLOSED CODE_FIX    
Severity: high CC: guido.iodice, lean-kernelbug, linville, mexsalem, wolkenschieber
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.28.2 Subsystem:
Regression: No Bisected commit-id:
Attachments: rtl8180: fix tx status reporting
0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch
0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch

Description drkludge 2009-01-31 12:29:10 UTC
Latest working kernel version: unknown... never worked for me
Earliest failing kernel version: 2.26.26, maybe earlier
Distribution: arch linux
Hardware Environment:
* ibm thinkpad a21m, 800 Mhz Pentium III (Coppermine) GenuineIntel
* lspci -vv:

<snip />
06:00.0 Ethernet controller: Belkin Device 701f (rev 20)
Subsystem: Belkin Device 701f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 3000 [size=256]
Region 1: Memory at 3c000000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ndiswrapper
Kernel modules: rtl8180
<snip />

(this is a pcmcia card)

Software Environment:

ndiswrapper v1.53
wireless_tools v29

Problem Description:

using ndiswrapper v1.53 with the windows net8185 driver, 'iwlist wlan0 scan'
shows 3 - 5 networks, with signal strengths ranging from 30 - 60%. using
the rtl8180 driver, 'iwlist wlan0 scan' shows at best one network, at
signal strength 9 - 16%, and cannot connect to the network i connect to
(almost) flawlessly with ndiswrapper.

i wish i could give more info than that, but if you ask, you shall receive.

fwiw, i remember months ago finding suggestions relating to the rate control algorithm selected by mac80211, now i can't find those threads for the life of me.

Steps to reproduce:

modprobe ndiswrapper # with net8185 installed
iwlist wlan0 scan
iwconfig wlan0 essid "network"
dhcpcd wlan0
#go online relatively happily!
modprobe -r ndiswrapper
modprobe rtl8180
iwlist wlan0 scan #if you're lucky, see a network
iwconig wlan0 essid "network"
#watch ap probe timeout
Comment 1 John W. Linville 2009-02-04 12:19:30 UTC

*** This bug has been marked as a duplicate of bug 11392 ***
Comment 2 drkludge 2009-02-04 14:42:20 UTC
i'm not sure this is actually the same bug as 11392... it seems from my reading that bug has the driver reporting the wrong values, but not interfering with connections. in other words, if i understand correctly, the driver works but lies.

in my case, the driver may be wrong about the signal quality, but it sure acts like it's telling the truth.  i can only "see" the one network, and i'm unable to connect to it; as if it actually were out of range:

dmesg <snip> with ndiswrapper:

Feb  4 10:11:32 laura ndiswrapper version 1.53 loaded (smp=yes, preempt=yes)
Feb  4 10:11:32 laura ndiswrapper: driver net8185 (Realtek,02/01/2007,5.1097.0201.2007) loaded
Feb  4 10:11:32 laura ndiswrapper 0000:06:00.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11
Feb  4 10:11:33 laura ndiswrapper: using IRQ 11
Feb  4 10:11:38 laura wlan0: ethernet device 00:17:3f:d6:bc:9c using NDIS driver: net8185, version: 0x50449, NDIS version: 0x500, vendor: 'Realtek RTL8185 Wireless LAN (Mini-)PCI NIC                                     ', 1799:701F.5.conf
Feb  4 10:11:38 laura wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
Feb  4 10:11:38 laura usbcore: registered new interface driver ndiswrapper
Feb  4 10:11:55 laura dhcpcd[415]: wlan0: dhcpcd not running
Feb  4 10:11:55 laura dhcpcd[416]: eth0: dhcpcd not running
Feb  4 10:11:55 laura dhcpcd[426]: wlan0: dhcpcd 4.0.7 starting
Feb  4 10:11:55 laura dhcpcd[426]: wlan0: broadcasting for a lease
Feb  4 10:11:59 laura dhcpcd[426]: wlan0: offered 192.168.1.100 from 192.168.1.1
Feb  4 10:11:59 laura dhcpcd[426]: wlan0: checking 192.168.1.100 is available on attached networks
Feb  4 10:12:04 laura dhcpcd[426]: wlan0: acknowledged 192.168.1.100 from 192.168.1.1
Feb  4 10:12:04 laura dhcpcd[426]: wlan0: leased 192.168.1.100 for 86400 seconds
# \/ modprobe -r ndiswrapper \/
Feb  4 15:28:54 laura ndiswrapper: device wlan0 removed
Feb  4 15:28:54 laura ndiswrapper 0000:06:00.0: PCI INT A disabled
# \/ modprobe rtl8180 \/
Feb  4 15:30:23 laura cfg80211: Using static regulatory domain info
Feb  4 15:30:23 laura cfg80211: Regulatory domain: US
Feb  4 15:30:23 laura 	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Feb  4 15:30:23 laura 	(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
Feb  4 15:30:23 laura 	(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Feb  4 15:30:23 laura 	(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Feb  4 15:30:23 laura 	(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Feb  4 15:30:23 laura 	(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Feb  4 15:30:23 laura 	(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
Feb  4 15:30:23 laura cfg80211: Calling CRDA for country: US
Feb  4 15:30:23 laura rtl8180 0000:06:00.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11
Feb  4 15:30:23 laura phy0: Selected rate control algorithm 'pid'
Feb  4 15:30:24 laura phy0: hwaddr 00:17:3f:d6:bc:9c, RTL8185vD + rtl8225z2
Feb  4 15:30:24 laura load-modules.sh: 'platform:regulatory' is not a valid module or alias name

since i'm using wicd, it will see interface when it comes up and try to connect.  i can't provide the output of dhcpcd's attempts to connect because right now iwlist doesn't see the network at all, but on those rare occassions when it does, it times out trying to probe the access point.

here are two runs of iwlist with the two drivers, for comparison's sake:

with ndiswrapper:

wlan0     Scan completed :
          Cell 01 - Address: 00:1F:F3:C1:99:5E
                    ESSID:"Manuel Arellano"
                    Protocol:IEEE 802.11g
                    Mode:Managed
                    Frequency:2.437 GHz (Channel 6)
                    Quality:32/100  Signal level:-75 dBm  Noise level:-96 dBm
                    Encryption key:on
                    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
                    Extra:bcn_int=100
                    Extra:atim=0
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK
          Cell 02 - Address: 00:1D:7E:41:7E:98
                    ESSID:"admin"
                    Protocol:IEEE 802.11g
                    Mode:Managed
                    Frequency:2.422 GHz (Channel 3)
                    Quality:48/100  Signal level:-65 dBm  Noise level:-96 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s
                    Extra:bcn_int=100
                    Extra:atim=0
          Cell 03 - Address: 00:14:95:1E:AB:B9
                    ESSID:"2WIRE359"
                    Protocol:IEEE 802.11g
                    Mode:Managed
                    Frequency:2.437 GHz (Channel 6)
                    Quality:39/100  Signal level:-71 dBm  Noise level:-96 dBm
                    Encryption key:on
                    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
                    Extra:bcn_int=100
                    Extra:atim=0

with rtl8180:

lan0     Scan completed :
          Cell 01 - Address: 00:1D:7E:41:7E:98
                    ESSID:"admin"
                    Protocol:IEEE 802.11g
                    Mode:Managed
                    Frequency:2.422 GHz (Channel 3)
                    Quality:9/100  Signal level:-65 dBm  Noise level:-96
dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s
                    Extra:bcn_int=100
                    Extra:atim=0

(sorry if re-opening is obnoxious.  if i'm really just pissing in the wind, please do close again.)
Comment 3 Guido 2010-01-08 09:44:12 UTC
I confirm the bug on linux 2.6.31 and 2.6.32:

lspci:
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20)


uname -r:
2.6.32-10-generic (Ubuntu kernel based on linux 2.6.32.2

iwconfig wlan0:
wlan0     IEEE 802.11bg  ESSID:"Conceptronic"  
          Mode:Managed  Frequency:2.452 GHz  Access Point: 00:80:5A:37:6C:A9   
          Bit Rate=1 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=34/100  Signal level=34/100  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

(the router is very near with PC, about 50 cm)
Comment 4 Wolken Schieber 2010-01-09 18:18:39 UTC
I confirm this bug on Linux 2.6.32.3.

Bit rate and signal is very weak.

lspci: 
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20) [LevelOne WNC-0301 rev 6]

uname:
Linux 2.6.32.3-atom #1 SMP Sat Jan 9 13:56:42 CET 2010 x86_64 GNU/Linux

iwconfig:
wlan0     IEEE 802.11bg  ESSID:"Name"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: MAC   
          Bit Rate=1 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=20/100  Signal level=20/100  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

distance to router:
approx. 5m

Ndiswrapper doesn't work since there are no working 64-bit drivers from LevelOne or Realtek. Realtek's linux drivers won't compile since Kernel 2.6.31.
Comment 5 Guido 2010-02-19 01:51:56 UTC
Today I use 

uname -r
2.6.32-13-generic

(ubuntu kernel based on latest upstream stable kernel)

I installed newest compat wireless by linux-backports-modules in Ubuntu. The
issue is still here.


lsmod | grep rtl
rtl8180                26419  0 
mac80211              210453  1 rtl8180
eeprom_93cx6            1333  1 rtl8180
cfg80211              130948  2 rtl8180,mac80211

filename:       /lib/modules/2.6.32-13-generic/updates/cw/rtl8180.ko
license:        GPL
description:    RTL8180 / RTL8185 PCI wireless driver
author:         Andrea Merello <andreamrl@tiscali.it>
author:         Michael Wu <flamingice@sourmilk.net>
srcversion:     2FF25434BD6684F625C53BB
alias:          pci:v00001186d00003300sv*sd*bc*sc*i*
alias:          pci:v00001799d00006020sv*sd*bc*sc*i*
alias:          pci:v00001799d00006001sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008180sv*sd*bc*sc*i*
alias:          pci:v00001799d0000701Fsv*sd*bc*sc*i*
alias:          pci:v00001799d0000700Fsv*sd*bc*sc*i*
alias:          pci:v000010ECd00008185sv*sd*bc*sc*i*
depends:        mac80211,eeprom_93cx6,cfg80211
vermagic:       2.6.32-13-generic SMP mod_unload modversions 586
Comment 6 John W. Linville 2010-04-29 15:37:01 UTC
Created attachment 26183 [details]
rtl8180: fix tx status reporting

This allows the rate control algorithm to do its job.  Does it help with this issue?
Comment 7 lf 2010-05-13 19:57:30 UTC
@ #6

I tried the patch, and it didn't seem to work. I guess it is too much to ask for a one-liner ;)

07:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20)
Comment 8 John W. Linville 2010-07-19 20:56:10 UTC
Created attachment 27160 [details]
0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch

Can you give this a try?
Comment 9 John W. Linville 2010-07-20 21:12:51 UTC
Created attachment 27171 [details]
0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch
Comment 10 Mexsalem 2010-08-17 20:50:22 UTC
I use an updated subsystem based on compat-wireless-2.6.35-1. It improved my Bit Rate up to 54 Mbit/s instead of fixed 1 MBit/s, but the signal is still weak (Link Quality=16/100  Signal level=16/100 ). I tried this patch but it didn't work for me.

mexsalem@GERICOM:~$ lspci -nnk | grep -i realtek -A2
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller [10ec:8185] (rev 20)
	Kernel driver in use: rtl8180
	Kernel modules: rtl8180, r8185b

mexsalem@GERICOM:~$ modinfo rtl8180
filename:       /lib/modules/2.6.32-24-generic/updates/drivers/net/wireless/rtl818x/rtl8180.ko
license:        GPL
description:    RTL8180 / RTL8185 PCI wireless driver
author:         Andrea Merello <andreamrl@tiscali.it>
author:         Michael Wu <flamingice@sourmilk.net>
srcversion:     01F194141F159398B338207
alias:          pci:v00001186d00003300sv*sd*bc*sc*i*
alias:          pci:v00001799d00006020sv*sd*bc*sc*i*
alias:          pci:v00001799d00006001sv*sd*bc*sc*i*
alias:          pci:v000010ECd00008180sv*sd*bc*sc*i*
alias:          pci:v00001799d0000701Fsv*sd*bc*sc*i*
alias:          pci:v00001799d0000700Fsv*sd*bc*sc*i*
alias:          pci:v000010ECd00008185sv*sd*bc*sc*i*
depends:        mac80211,eeprom_93cx6,cfg80211
vermagic:       2.6.32-24-generic SMP mod_unload modversions 586 

mexsalem@GERICOM:~/Downloads$ sudo patch -b -p0 < PATCH_v2_rtl8180_improve_signal_reporting_for_rtl81852_hardware.patch
patching file b/drivers/net/wireless/rtl818x/rtl8180_dev.c
Hunk #1 FAILED at 103.
Hunk #2 FAILED at 130.
2 out of 2 hunks FAILED -- saving rejects to file b/drivers/net/wireless/rtl818x/rtl8180_dev.c.rej
Comment 11 John W. Linville 2010-08-17 20:57:53 UTC
It looks like the patch failed to apply for you...
Comment 12 John W. Linville 2010-08-17 20:58:47 UTC
FWIW, you need to use "-p1" as an argument to patch.
Comment 13 Mexsalem 2010-08-19 21:33:31 UTC
Because the patch failed to apply for my version of the rtl8180_dev.c, I added the patch manually. Here is the extract of the modified rtl8180_dev.c :

mexsalem@GERICOM:~/Downloads/compat-wireless-2.6.35-1/drivers/net/wireless/rtl818x$ cat -n rtl8180_dev.c | head -n 109 | tail -n 7
   103	{
   104	struct rtl8180_priv *priv = dev->priv;
   105	unsigned int count = 32;
   106	u8 signal;
   107	while (count--) {
   108		struct rtl8180_rx_desc *entry = &priv->rx_ring[priv->rx_idx];
   109		struct sk_buff *skb = priv->rx_buf[priv->rx_idx];
 
mexsalem@GERICOM:~/Downloads/compat-wireless-2.6.35-1/drivers/net/wireless/rtl818x$ cat -n rtl8180_dev.c | head -n 141 | tail -n 12 
   130	skb_put(skb, flags & 0xFFF);
   131	
   132	rx_status.antenna = (flags2 >> 15) & 1;
   133		
   134	rx_status.rate_idx = (flags >> 20) & 0xF;
   135	/* TODO: improve signal/rssi reporting for !rtl8185 */
   136	signal = (flags2 >> 17) & 0x7F;
   137	if (rx_status.rate_idx > 3)
   138		signal = 90 - clamp_t(u8, signal, 25, 90);
   139	else
   140		signal = 95 - clamp_t(u8, signal, 30, 95);
   141	rx_status.signal = signal;

Then i compiled and installed it, now the signal varies from 16% to 33% max. - but this is still to weak compared to the expected signal. The Network-Manager-Applet shows 1-2 lines for the signal.

modinfo rtl8180 | grep version
srcversion:     3BDDA4655443D3A170CCAE9
vermagic:       2.6.32-24-generic SMP mod_unload modversions 586
Comment 14 John W. Linville 2010-08-23 14:51:10 UTC
Well, I'm sorry you are not happy.  But as this is an improvement, it is based on the vendor-provided driver, and I have no better (or other) reference then this is about as good as you can expect it to get.

commit 8b74964c73ca9eed7078388d871cc7fae973cb63
Author: John W. Linville <linville@tuxdriver.com>
Date:   Mon Jul 19 16:35:20 2010 -0400

    rtl8180: improve signal reporting for rtl8185 hardware
    
    The existing code seemed to be somewhat based on the datasheet, but
    varied substantially from the vendor-provided driver.  This mirrors the
    handling of the rtl8185 case from that driver, but still neglects the
    specifics for the rtl8180 hardware.  Those details are a bit muddled...
    
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

Also, this:

commit 8b73fb8e29e9ae0458d36cc0dc25e2717587dfd4
Author: John W. Linville <linville@tuxdriver.com>
Date:   Wed Jul 21 16:26:40 2010 -0400

    rtl8180: improve signal reporting for actual rtl8180 hardware
    
    Adapted from Realtek-provided driver...
    
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Tested-by: Pauli Nieminen <suokkos@gmail.com>