Bug 11392

[   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

I marked this as a regression.

We'd be very interested in finding out of 2.6.26 had the
bug as well, please.

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?

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"

okias, can you try reverting the patch in comment 3?

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...

Hmm, my rtl8187B doesn't usually go over half i.e. 50/100.

Created attachment 18193 [details]
rtl8187-do-not-report-ACKs-if-USB-Tx-status-is-non.patch

Normalize quality value for 100-point scale.

Crap, wrong patch...

Created attachment 18194 [details]
0002-rtl8180-normalize-quality-measurment-for-100-point.patch

Normalize quality value for 100-point scale.

Patch seems obvious, but I'd be happy for someone else to test it...especially someone w/ a "high quality" wireless environment... :-)

Still doesn't seem right -- numbers are very low (<10) and anecdotaly seems to move in the wrong direction...

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?

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.

*** Bug 12588 has been marked as a duplicate of this bug. ***

Hey guys, would you reconsider giving some love to this bug?

Problem with number over 100 (like "Link Quality: 133/100") still remaining in 2.6.29...

http://ubuntuforums.org/showthread.php?t=1095258&highlight=Alfa+AWUS036H

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?

(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.

Someone sent the link to me and I just didn't want to forget it -- don't take it as any more than that...

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.

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.

Created attachment 21918 [details]
logs and screenshots of test cases

(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.

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.

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

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

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.

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

Probably fixed in .30, work fine now.

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 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.

Is the patch already included in 2.6.35-rc4?

excuse me, my last comment was for this bug: https://bugzilla.kernel.org/show_bug.cgi?id=11176