Bug 11392 - RTL8180 incorect link quality in iwconfig
Summary: RTL8180 incorect link quality in iwconfig
Status: CLOSED UNREPRODUCIBLE
Alias: None
Product: Networking
Classification: Unclassified
Component: Wireless (show other bugs)
Hardware: All Linux
: P1 low
Assignee: John W. Linville
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-21 08:08 UTC by David Heidelberg (okias)
Modified: 2010-07-09 07:48 UTC (History)
9 users (show)

See Also:
Kernel Version: 2.6.29
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
rtl8187-do-not-report-ACKs-if-USB-Tx-status-is-non.patch (1.44 KB, patch)
2008-10-07 12:23 UTC, John W. Linville
Details | Diff
0002-rtl8180-normalize-quality-measurment-for-100-point.patch (1.11 KB, patch)
2008-10-07 12:25 UTC, John W. Linville
Details | Diff
logs and screenshots of test cases (223.36 KB, application/octet-stream)
2009-06-15 11:44 UTC, Hamza Bhatti
Details

Description David Heidelberg (okias) 2008-08-21 08:08:11 UTC
Latest working kernel version: probably 2.6.25 (maybe 2.6.26)
Earliest failing kernel version: 2.6.27
Distribution: Debian
Hardware Environment: PIII 500Mhz, 700M RAM, RTL8180L
Software Environment:
Problem Description:

server:~# iwconfig wlan0
wlan0     IEEE 802.11b  ESSID:"AP1"
          Mode:Managed  Frequency:2.452 GHz  Access Point: 00:4F:62:01:E3:EE
          Bit Rate=2 Mb/s   Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Encryption key:off
          Power Management:off
          Link Quality=133/100  Signal level:15/65
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0



Steps to reproduce: try 10x "iwconfig wlan0" and you probably hit value over 100 (looks like random values)..
Comment 1 David Heidelberg (okias) 2008-08-21 08:15:17 UTC
[   16.704035] rtl8180 0000:00:0c.0: PCI INT A -> Link[LNKA] -> GSI 15 (level, low) -> IRQ 15                                                                                                                       
[   16.784033] phy0: Selected rate control algorithm 'pid'                                                                                                                                                          
[   18.020034] phy0: hwaddr 00:50:fc:49:08:c1, RTL8180 + GCT                                                                                                                                                        
[   24.016031] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   24.768031] wlan0: authenticate with AP 00:4f:62:01:e3:ee
[   24.769391] wlan0: authenticated
[   24.769391] wlan0: associate with AP 00:4f:62:01:e3:ee
[   24.771223] wlan0: RX AssocResp from 00:4f:62:01:e3:ee (capab=0x1 status=0 aid=1)
[   24.771223] wlan0: associated
[   24.772029] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   34.949665] wlan0: no IPv6 routers present
Comment 2 Andrew Morton 2008-08-21 09:38:08 UTC
I marked this as a regression.

We'd be very interested in finding out of 2.6.26 had the
bug as well, please.
Comment 3 John W. Linville 2008-08-22 07:34:07 UTC
I suspect this relates to the following commit:

ommit 566bfe5a8bcde13188a356f77666f8115813cf31
Author: Bruno Randolf <br1@einfach.org>
Date:   Thu May 8 19:15:40 2008 +0200

    mac80211: use hardware flags for signal/noise units
    
    trying to clean up the signal/noise code. the previous code in mac80211 had
    confusing names for the related variables, did not have much definition of
    what units of signal and noise were provided and used implicit mechanisms fr
    the wireless extensions.

    ....

Could you revert that one and try to replicate the problem?  Otherwise, could I persuade you to do a git bisect?
Comment 4 David Heidelberg (okias) 2008-08-26 03:09:13 UTC
Sorry, lastest working version doesnt exist, because this "Signal Quality" is new from 2.6.27. Previous kernel (<2.6.26) showing only "Signal level"
Comment 5 John W. Linville 2008-09-15 16:13:00 UTC
okias, can you try reverting the patch in comment 3?
Comment 6 David Heidelberg (okias) 2008-09-16 10:05:49 UTC
I'm sorry, I can't, I'm using precompiled Debian kernel... but I found in some dicussion: something about Link quality determination with rtl8180 is just random...
Comment 7 Hin-Tak Leung 2008-10-03 11:59:00 UTC
Hmm, my rtl8187B doesn't usually go over half i.e. 50/100.
Comment 8 John W. Linville 2008-10-07 12:23:39 UTC
Created attachment 18193 [details]
rtl8187-do-not-report-ACKs-if-USB-Tx-status-is-non.patch

Normalize quality value for 100-point scale.
Comment 9 John W. Linville 2008-10-07 12:24:45 UTC
Crap, wrong patch...
Comment 10 John W. Linville 2008-10-07 12:25:41 UTC
Created attachment 18194 [details]
0002-rtl8180-normalize-quality-measurment-for-100-point.patch

Normalize quality value for 100-point scale.
Comment 11 John W. Linville 2008-10-07 12:26:55 UTC
Patch seems obvious, but I'd be happy for someone else to test it...especially someone w/ a "high quality" wireless environment... :-)
Comment 12 John W. Linville 2008-10-08 12:22:16 UTC
Still doesn't seem right -- numbers are very low (<10) and anecdotaly seems to move in the wrong direction...
Comment 13 C. Reis 2008-11-09 14:46:30 UTC
I'm using the latest version of Ubuntu (Intrepid Ibex 8.10), and I've experienced a weak link quality signal (about 5 to 15%) in network-manager and the command iwconfig wlan0, although my connection speed seems fine and the link quality is good in Windows XP and the prior Ubuntu release, Hardy Heron 8.04.
I just wanted to ask if there's a way to help you with this issue in spite of me being a pretty unexperienced linux user?
Comment 14 Diego Escalante Urrelo 2008-11-11 23:24:10 UTC
John,

currently I have signal reports of 5~10% despite being one meter from the router, even when sit right in front I have that readings. I can confirm the issue happens (at least the ultra low quality bug).

As reference, this is my iwconfig output:
wlan0     IEEE 802.11b  ESSID:"cow"  
          Mode:Managed  Frequency:2.427 GHz  Access Point: 00:11:F5:50:49:B7   
          Bit Rate=5.5 Mb/s   Tx-Power=27 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Power Management:off
          Link Quality=16/100  Signal level:-130 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

I'm bitwise impaired so I can't really comment on your patch, but in a very gross guess I would say it will give me 0.something link quality :-).

And as anecdotical info, this could be the cause to the spontaneous drops of connection I have suffered with this driver.
Comment 15 John W. Linville 2009-02-04 12:19:30 UTC
*** Bug 12588 has been marked as a duplicate of this bug. ***
Comment 16 Diego Escalante Urrelo 2009-04-11 01:20:35 UTC
Hey guys, would you reconsider giving some love to this bug?
Comment 17 David Heidelberg (okias) 2009-05-08 13:22:28 UTC
Problem with number over 100 (like "Link Quality: 133/100") still remaining in 2.6.29...
Comment 19 Diego Escalante Urrelo 2009-06-07 19:23:11 UTC
Well that seems for rtl8187, that I understand is the USB variant of this chip, my problem is with the Cardbus version (that I understand is also de PCI one), rtl8180.
With older kernels, the driver in http://rtl-wifi.sourceforge.net/wiki/Main_Page was working perfect, although now it doesn't build easily anymore.

I'm currently using .30-rc8 in Debian and the disconnect problem persists, mostly when having a lot of simultaneous requests, if I trigger a disconnect while doing a ping, I get this when the disconnect happens:

ping: sendmsg: No buffer space available

A small note, this disconnect is practical but not formal, I mean that according to NetworkManager and any other connectivity aware thing will say that I'm online, actually if I disconnect with ifconfig/iwconfig etc I can reconnect again and everything but despite being 'connected' the network will be useless.

Only after unloading and reloading the module I'll be able to connect again and get actual network input and output.

How can I help fix this?
Comment 20 Hin-Tak Leung 2009-06-09 12:32:36 UTC
(In reply to comment #18)
> http://ubuntuforums.org/showthread.php?t=1095258&highlight=Alfa+AWUS036H

Hmm, that url just says, essentially, switch to the vendor driver (plus newer-kernel porting patch).

 (In reply to comment #19)
> With older kernels, the driver in
> http://rtl-wifi.sourceforge.net/wiki/Main_Page was working perfect, although
> now it doesn't build easily anymore.

Could do with more details here - that work was based on the vendor driver but made some attempts to the new stack.
Comment 21 John W. Linville 2009-06-09 13:05:04 UTC
Someone sent the link to me and I just didn't want to forget it -- don't take it as any more than that...
Comment 22 Hin-Tak Leung 2009-06-09 20:51:16 UTC
Both of the links/comments seem to indicate that the vendor driver does something which the in-kernel driver does not do (yet) or vice versa.
Comment 23 Hamza Bhatti 2009-06-15 11:27:28 UTC
Can confirm.

Hardware:

  Dell Inspiron 9400 laptop
  Alfa AWUS036H wireless USB adapter (RTL8187 chipset)

Tested on: 

  Ubuntu 8.04, 8.10 and 9.04


Steps:

  1. Boot into the distribution (in this case, Ubuntu) using the LiveCD.
  2. After the desktop finishes loading, click on the NetworkManager icon to    
     view the list of available networks. 

Issue:

  - All listed wireless networks are reported as having the same signal stength.  
   (a constant 16-17%)

Expected:

  - A strong (approx. 98%) signal strength reported for my own access point.
  - Signal strengths for other wireless networks to be reported based on factors 
    of distance and link quality.


Remarks:

  - Connecting to a wireless network does not result in its signal strength to   
    be reported accurately.
  - Moving closer to the access point does not result in a change in the  
    reported signal strength.

Affects:

  2.6.24-23 (Ubuntu 8.04) - no
  2.6.27-7 (Ubuntu 8.10) - yes
  2.6.28-11 (Ubuntu 9.04) - yes
 
Notes:

  - Signal strengths reported in 2.6.24-23 for each wireless network listed in 
    NetworkManager are accurate.
  - Signal strengths are defined to be accurate if they are approximately the 
    same as the values reported by the vendor-supplied RTL8187 Wireless LAN 
    utility for Windows XP. (see screenshot)

Attachments:

  - dmesg
  - iwlist wlan1 scan
  - iwlist wlan1 rate
  - lsusb
  - ifconfig -a
  - uname -a
  - screenshots


Sorry about the delay, John. You may remember that I gave you the link that you mentioned in comment #18 on IRC. That driver and the patch was released by the aircrack-ng team in order to provide injection support for the RTL8187 in monitor mode. 

The reason I pointed that out is that it has the interesting side-effect that once one compiles, patches, and uses those drivers, the signal strength reported for the wireless network that one is actually connected to is accurate. However, the signal strengths of the rest of the wireless networks listed in NetworkManager is still inaccurate. (a constant 16-17%)

You mentioned that there is a possibility that the math used to do the conversions is incorrect. I'm going through the rtl8187.h on my own looking for the appropriate function, but I'm finding it hard to understand at the moment. Is there a particular resource you could point me towards?

Please advise how I can be of further assistance, because I would be very interested in helping to see this fixed in the next release.
Comment 24 Hamza Bhatti 2009-06-15 11:44:22 UTC
Created attachment 21918 [details]
logs and screenshots of test cases
Comment 25 Hin-Tak Leung 2009-06-15 15:35:43 UTC
(In reply to comment #24)
> Created an attachment (id=21918) [details]
> logs and screenshots of test cases

Can you try compat-wireless ? there has been a lot of changes since 2.6.28, which is what the most recent kernel you are using.
Comment 26 Hamza Bhatti 2009-06-15 22:03:58 UTC
Can confirm that using compat-wireless resolves the issue

Tested on: 

  Ubuntu 9.04


Steps:

  1. Installed Ubuntu 9.04 to the hard drive.
  2. sudo apt-get install linux-backports-modules-jaunty
  3. Restart Ubuntu

Results:

NetworkManager reports accurate signal strengths of all wireless networks.

iwlist wlan1 scan 
wlan1     Scan completed :
          Cell 01 - Address: 00:02:6F:55:24:8C
                    Channel:1
                    Frequency:2.412 GHz (Channel 1)
                    Quality=55/70  Signal level=-55 dBm  
                    Encryption key:on
                    ESSID:"EnGenius"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 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=0000000007675181
                    Extra: Last beacon: 100ms ago
                    IE: Unknown: 0008456E47656E697573
                    IE: Unknown: 010882848B0C12961824
                    IE: Unknown: 030101
                    IE: Unknown: 2A0100
                    IE: Unknown: 32043048606C
                    IE: Unknown: DD0900037F010100200000

iwlist wlan1 rate
wlan1     unknown bit-rate information.
          Current Bit Rate=5.5 Mb/s

Remarks:

The bit rate appears to be much lower than expected after connecting to the wireless network.

Please advise.
Comment 27 Hamza Bhatti 2009-06-15 22:09:01 UTC
Disregard remarks in previous comment.

Within a few minutes of connecting to the wireless network, the reported bit rate is correct.

iwlist wlan1 rate
wlan1     unknown bit-rate information.
          Current Bit Rate=48 Mb/s
Comment 28 Diego Escalante Urrelo 2009-06-15 22:11:50 UTC
I wonder if you can confirm that after stressing the connection with multiple simultaneous downloads or similar it timeouts. Like in my comment #19 http://bugzilla.kernel.org/show_bug.cgi?id=11392#c19
Comment 29 Hamza Bhatti 2009-06-18 13:16:55 UTC
I tested the connection yesterday by downloading an ISO file using the torrent provided by the distribution. At the same time, I was browsing the web (which was, as expected, slow) and update manager was downloading ~50 MB of updates as well.

In three hours of testing, I was unable to cause the connection to timeout. 

Network History (from System Monitor):
Total Received: 454.9 MB
Total Sent: 38.9 MB

The average receiving speed observed, as expected, was ~60 KB/s.

Therefore, I cannot confirm that the connection times out after it is stressed using simultaneous downloads. However, the Alfa AWUS036H USB wireless adapter that I have utilizes the RTL8187 chipset. Unfortunately, I don't have any hardware available to test the RTL8080 chipset.
Comment 30 matt.t.grimm 2009-06-22 15:47:15 UTC
I can confirm that the steps in comment 26 fix the issue for me. 

Ubuntu 9.04 (Jaunty)
RTL8187 wireless chipset

Signal strenths for all detected APs were a constant 14% before installing linux-backports-modules-jaunty. Random disconnects were frequent as well, especially during heavy usage. After installing this package, my AP (6 feet away) shows 90% and the other neighborhood APs show accurate signal strengths (as compared with what Kismet reports).


$ uname -r
2.6.28-13-generic
$ iwconfig wlan0
wlan0     IEEE 802.11bg  ESSID:"<snip>"  
          Mode:Managed  Frequency:2.432 GHz  Access Point: <snip>   
          Bit Rate=54 Mb/s   Tx-Power=27 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          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:0   Missed beacon:0
Comment 31 David Heidelberg (okias) 2009-10-04 17:29:20 UTC
Probably fixed in .30, work fine now.
Comment 32 Guido 2010-01-08 09:38:47 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 33 Hal V. Engel 2010-07-09 06:26:58 UTC
I can conform that this bug is still in 2.6.34:

uname -r
2.6.34-gentoo

# iwconfig wlan0
wlan0     IEEE 802.11bg  ESSID:"belkin54g3508"
          Mode:Managed  Frequency:2.447 GHz  Access Point: 00:11:50:0F:9B:D9
          Bit Rate=54 Mb/s   Tx-Power=20 dBm
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=15/100  Signal level=15/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Router is perhaps 30 feet away but I am using a very high gain antenna and the same hardware setup report 100% in Windows XP.
Comment 34 Guido 2010-07-09 07:47:11 UTC
Is the patch already included in 2.6.35-rc4?
Comment 35 Guido 2010-07-09 07:48:22 UTC
excuse me, my last comment was for this bug: https://bugzilla.kernel.org/show_bug.cgi?id=11176

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