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
*** This bug has been marked as a duplicate of bug 11392 ***
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.)
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)
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.
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
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?
@ #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)
Created attachment 27160 [details] 0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch Can you give this a try?
Created attachment 27171 [details] 0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch
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
It looks like the patch failed to apply for you...
FWIW, you need to use "-p1" as an argument to patch.
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
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>