Bug 14168

Addendum: Other regression whith kernel 2.6.31: if USB cord is disconnected from pc with rtl8187 module loaded, I have allways a kernel freeze and hard reboot is needed. Soft reboot don't works (alt + print + REISUB). 
Ciao

I've done more testing with the latest vanilla kernel 2.6.31.4 ...
The results are as follows:
If the signal is less than-70dBm (from airmon-ng) can connect only with the PID algorithm

With stronger signals,(>65 dBm)  even the minstrel algorithm works well.

Instead using kernel 2.6.29.6 I can use minstrel for both strong or weak signals with good performances.
Ciao !

IIRC, this device does a poor job of reporting Tx status.  This leaves minstrel with insufficient information to do it's job... :-(

Hi, John, many thanks for your kind answer.
What can we do? 
I think that minstrel works fine in 2.6.29.x kernels (right ?) I am not a kernel wireless hacker... 

Must always use PID with 2.6.3x ? Or use old kernels with minstrel ?
Ciao !

Hmmm...so you are saying that minstrel and rtl8187 worked well together prior to 2.6.30?

Yes, John, I'm just saying this ...
I've been using  kernel 2.6.29.6 with good results with the minstrel algorithm... (and signals <70 dBm)... 
I have problems starting from version 2.6.30

This looks like it could relate...

commit 2f47690ed42a85820783dee7f16ae47edadf8fad
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Fri Jan 23 11:40:22 2009 -0600

    rtl8187: Fix driver to return TX retry info for RTL8187L
    
...

Created attachment 23548 [details]
0001-Revert-rtl8187-Fix-driver-to-return-TX-retry-info.patch

Try this?

Hi John, I will try your patch  against kernel 2.6.31.4 .
Please stay tuned .... :)

Hi John, it seems that your patch works fine... 

I try now with kernel 2.6.31.5, latest compat-wireless package (27-10-2009) and Alfa 036h USB WIFI interface ...

Now I can connect the AP with good performance with signal abt -70dBm. WOW !

But I have other bug/regression after kernel 2.6.30 : when usb cord is disconnected, kernel always hangs if rtl8187 module is not first removed with modprobe -r...
This issue does not happen using kernel 2.6.29.6. ...

I should open another bug report for this topic?
Thanks
Errico :)

Well, I'm not too interested in just reverting a previous patch.  Hopefully Larry has some insight.  Maybe disabling the rate fallback mechanism is the culprit?

The RealTek specs are very clear about how an RTL8187L returns the retransmission information. In addition, I had E-mail contact with a RealTek engineer. This information was the basis for the patch in commit 2f47690ed42a8582078. I'm quite confident in it, but I will test, particularly for weaker signals. Without it, the number of tries is a constant - I remember zero, but that may be wrong.

The kernel freezes that the OP reports are a separate bug that affects both RTL8187L and RTL8187B. It also fails with modprobe -r, just not every time. I am currently trying to find the cause. A Bugzilla has not yet been filed.

Larry and John, thanks for your interest...

Now, I am using rtl8187 driver with patch reverted, and minstrel works fine.

If necessary, I could conduct new tests, let me know.

@ Larry, I too have found that sometimes modprobe-r does not prevent the kernel hangs before removing the USB plug.

Ciao :)

E.P.

Could you provide the output of 'dmesg | grep rtl'? I would like to know what cut you have.

dmesg | grep rtl results:

phy1: hwaddr 00:c0:aa:aa:aa:aa, RTL8187vB (default) V1 + rtl8225z2
rtl8187: Customer ID is 0xFF
Registered led device: rtl8187-phy1::tx
Registered led device: rtl8187-phy1::rx
rtl8187: wireless switch is on
usbcore: registered new interface driver rtl8187


I have changed only mac address ...

I have finally gotten a chance to test my RTL8187L and RTL8187B using the mistrel rate-setting method using kernel 2.6.32-rc5 from wireless-testing. My results are as follows:

RTL8187L

Dist to AP     Signal Strength      Bit Rate        Max TX Transfer Rate

2 m             -34 dBm             54 Mb/s          23 Mb/s
20 m            -54 dBm             36-54 Mb/s       22 Mb/s
in Basement     -59 dBm             36 Mb/s          15 Mb/s
in Garage       -71 dBm             18 Mb/s          7 Mb/s

RTL8187B

2 m             -26 dBm             36 Mb/s          17 Mb/s
20 m            -47 dBm             11 Mb/s          4 Mb/s

As you can see, my RTL8187L is hardly phased by signals 25 dBm down from the 2 m value, and the mistrel rate seems to be exactly what it should be. My device reports the same cut/version as yours. Between -60 and -70 dBm the performance falls off rather quickly, but I still get good throughput.

The performance of the RTL8187B is not as good as the L; however, the patch in question does not affect that model, only the L.

Hello! 

I'm going to do the test using the old 2.6.29.6 kernel and the latest vanilla 2.6.32-rc5 with and without your patch

The signal of AP is about -72 dBm -74 dBm with directional antenna on ALFA 036H (RTL8187L) 

The AP is abt 50 m from me and use vertical omni antenna.

I use mandriva 2009.1 64 bit version, and will check the link quality with wireshark and ping.


Tonight, I also tried the latest Ubuntu Live 9.10 x64 without success. 

I can connect the AP simply but can not even ping to the IP's address... :-(
(with same conditions of signal, interface and antennas)

Hello! Sorry for the delay ... 

I've done more testing and here are the results:

1) kernel 2.6.31.5 (Mandriva 2010-x64) 


Signal down to -72  -73 dBm 

I have a good connection, good throughput (same results of Larry)

Signal down to -74 -76 dBm 

I can stably connect AP  but I have no throughput at all (no ping, only infinite sequence of arping packets)


Signal down to -78 -79 dBm - no AP connection



2) kernel 2.6.31.5 with Larry's patch reverted

I have acceptable throughput down to -75 -76 dBm signal, but the connection is more unstable and  AP sometimes disconnect at lower signals.
 
Conclusions:

With original driver, I have a quick degradation of link throughput between -70 and -74 dBm (really like a step).

Instead, with Larry's patch reverted, I noticed a smooth throughput degradation and signal down to -76 dBm is still usable.

I hope this may help.
Ciao!

E.P.

Created attachment 23942 [details]
Revert rate fallback disable

Please try this patch. It re-enables the RATE_FALLBACK mechanism in the hardware. With it enabled, the hardware will retry the transmit, but not report the true statistics to the rate-control mechanism in mac80211.

Errico: I am pretty disgusted with you. I went to the trouble of preparing a patch for you to test. You, however, cannot be bothered to test that patch. I should mark this thread INVALID and close it, but I will give you two more days. If you have not responded by then, I will close the Bug.

Hi Larry! 
Sorry for delay but I am very busy at moment for my family... Please do not blame me, I am not a professional beta tester, but only a hobbist.

I have already tested your latest patch (revert rate fallback) against kernel 2.6.31.6 without success, the behavior is pretty the same for a normal user like me.

Results:

I have a very stable connection to AP at -74 -75dBm but no throughput at all (no ping, no browsing, etc) with and without your latest patch.

At moment older kernel 2.6.29.6 remains really the most performant with weak signals although the AP connection is more unstable.

If you have other patch to test please let me know, I will glad to help driver development and check for regressions. 

Thanks
E.P.

Larry, please note that I applied your latest patch (revert rate fallback disable) to a vanilla 2.6.31.6 kernel 
(without patch Revert-rtl8187-Fix-driver-to-return-TX-retry-info posted by John W Linville), it's right choice ?

Yes, "revert rate fallback disable" is the only patch you should have applied.

Larry I have to report some other (strange?) observation :

The network manager (of Mandriva 2010, or Ubuntu 9.10) indicates a signal level higher in percentage (45% or so) I have a rock solid connection, but no throughput...


With earlier Mandriva 2009.1 or Ubuntu 8.10 (live CD) I have a lower percentage (only one or two segments 25%-30% max) but I can connect AP and have a quite usable link, with a some more (acceptable) connection instability.

Minstrel is always default algorithm in these live distributions. 

Ciao :-) 

E.P.

The algorithm that calculates has been changed. That probably accounts for the difference. Those numbers have no absolute meaning. You can only compare the relative results of two stations when using the same software.

Does Ubuntu 9.10 get an IP? I don't understand the "rock solid connection", but no throughput.

I will download and burn a 9.10 Live CD and see what I get.

Yes, ubuntu 9.10 like mandriva 2010 get a dynamic IP smoothly and flawlessly...

Connection is solid because I have no disconnection after long time, but I cannot ping even AP's address ... 100% packets lost!

Wireshark shows only a large stream of arping packets :-(

I understand that algorithm that calculates percentage has been changed, but I think that is strange to get a 45% - 46% level with a very weak signal of -74 -75 dBm and even one ping packet. 

I think that a 20% - 25% level and some disconnections would be more realistic in this marginal conditions and this behavior is similar to window$ driver... 

Larry you do not agree with me?

That behavior comes from mac80211. It takes the signal provided by the driver (in dBm) and range limits it to -110..-40 to get the reported signal. The quality value is then obtained by adding 110. The percentage found by dividing by 70. As an example, a signal of -75 dBm yields a quality of 35 and a level of 50%.

At the low end, the RTL8187L is 8-10 dBm higher than I get for b43, which shows how my calibration is breaking down. Not too surprising as it is a linear approximation to a rather complicated equation.

Larry's test patch left-out the rtl8187b bits, which according to comment 15 might be important...

Created attachment 24094 [details]
rtl8187-restore-rate-fallback.patch

Try this one?

Ok John, I will try soon your latest patch.
E.P.

Hello John, I tried your patch but the result looks the same. 

The driver included in kernel 2.6.29.6 is always more performant at lower signal strength.
Ciao

Well, at least that takes the blame off the rate fallback part...? :-)

Yes, I think that isn't the right direction...

What is the right direction?

Besides the rate fallback change, the other part of that patch was returning a _CORRECT_ number of tries for a transmit. Previously, the code returned 0. Obviously, that can never be correct - it is tries, not retries. I placed printk statements in the code that reports this information to mac80211 and all looks OK. I also went as far from my AP as I could get - the temperature here is -15 C and I didn't want to go outside. With a reported signal of -63 dBm, I got tcpperf transmit throughput of 12 Mb/s and mistrel selected a 54 Mb/s rate.

Just to test, I used the initial patch above to do as you recommend and revert the "rtl8187: Fix driver to return TX retry info" patch. At a distance of 2 m from my AP with a reported signal of -33 dBm, the rate never went above 1 Mb/s and the throughput was 0.9 Mb/s!

I do not know why your system behaves so differently from mine, but reverting the patch would break my system at all signal levels.

@ Larry
Could be something else? 

What are the differences between driver in kernel 2.6.29.6 and 2.6.30 or newer ones ?

When I revert "rtl8187: Fix driver to return TX retry info", I got an usable link  at 1 MB/s rate and download is abt 0,7 - 0,8 Mb/s (same as your results but
with lower signals strength) 

At -75, -76 dBm, and with signals from more than 10 AP close to me, it's very difficult to obtain a rate above 1 MB/s ! 

Withouth this patch reverted, I got no link, only DHCP IP address and link stops 

Please note that using vanilla kernel 2.6.29.6 and minstrel in the same conditions link is more responsible, with less packet retries, and few ping lost.
 
For this reason I think that revert TX retry info isn't the right answer.
 
P.S. At -63 dBm I also have a good throughput at 54 Mb/s rate, no problem at all.

I just remembered that this patch was required by a change in mac80211. Before,
it treated a returned value of 0 as indicating success with no retries. After
the change, 0 became a failure for every transmit, which explains what I saw
above. I'm not quite certain when the mac80211 change occurred - just before my patch.

If we were to revert the patch, you might get throughput at -75 dBm, but performance at stronger signals will be awful.

I finally made my device get low signals without having to get cold. I found a metal can that I could slide over the USB dongle. While doing this I got the transmit rate (Mb/s) from tcpperf and the signal strength (dBm) from a scan and from iwconfig. My results are:

tcpperf rate      iwconfig       iwlist scan

   N/C              -70             -74
   0.05             -74             -70
   1.09             -73             -66
   2.50             -70             -66
   6.34             -67             -68

At very weak signals, there is a lot of jitter. I have no idea why iwconfig and iwlist give different results.

@ Larry

I think that your results are similar to mine (no throughput at -74 dBm), and I agree with your latest statement in comment #36.

To revert the patch isn't the right answer to the problem but is only a workaround from my point of view. 

How could we do to get the drivers performance as much as that of the kernel 2.6.29 or window$ driver at weak signals?

I tried to build 2.6.29.6 so that I could match your system. With it, I could not even make a connection at 2 m. Rather than try to find what was wrong there. I just went back to more productive work.

Larry:
I do not know what would be your problem with kernel 2.6.29.6, anyway thanks for your kind efforts. 

I do not know what else could be done.

I will try also to use the win$'s driver with ndiswrapper or realtek's driver or will buy an antenna with more gain...  :-O

E.P.

I have the same problem with my alfa awus036h 1000mw card, i also own the 500mw card and am currently using backtrack 4 pre final with kernel 2.6.30.9. I blacklisted rtl8187L and installed r8187 patched driver which is available here: http://forum.aircrack-ng.org/index.php?topic=5755.0

This driver works even at -70dBi + however it is incompatible with networkmanager of kde 3.5 and i was told that it semi works with wicd so i am using that but even with wicd, it wont connect to wep/wpa and does not show signal strength unless connected to an AP. I have to manually connect from the shell if i want to use wep/wpa. I have never tried wpa so i dont even know if that will work but wep seems to connect using shell.

Now i wanted to use kubuntu 9.10 but the rtl8187 driver that comes with it has the same issues already reported. Closer AP works fine, farther AP cannot even ping gateway. With my 1000mw card i had better performance in 9.10 obviously because of its higher power but that does not fix this driver issue. 

The above patched r8187 driver that i mentioned does not compile in kernel 2.6.31+ so it cannot be used. However i received a driver from Realtek that does seem to compile in kernel 2.6.31/32 but does not seem to work. Networkmanager detects it and shows all AP, but while trying to connect to wep enabled network, it kept asking me for the key over and over. Also in karmic 9.10 you cannot manually connect to a network from shell so i was unsuccessul at that aswell. Here is the driver for your reference. Hope it helps in some way to fix this problem. I am waiting for a solution to this problem so i can install 9.10 or mandriva 2010 for good.

http://www.4shared.com/file/188631523/a725eefa/rtl8187L_linux_26103901042010r.html

I also contacted Realtek again and im hoping they have a new solution, i'll post soon as i get something. 

Thanks

Hi Bilal, I will try Realtek latest driver against latest kernels. Stay tuned please, ciao !

Bilal, I can give you a workaround: compile and install the kernel 2.6.29.6, rtl8187 works pretty well with weak signals... 

I use now mandriva 2010 with 2.6.31 default kernel, but I reboot and switch to 2.6.29.6 when small signal connections are available.

well i ran a live mandriva one yesterday and connected to my primary hotspot which was around 47% signal or so yet it wouldnt ping gateway(the same conenction works flawless in Backtrack 4 with r8187 driver). Is there any difference in mandriva one and mandriva 2010 ? i havent tried that yet cuz its like 4.5gb in size. Although im interested in using kubuntu 9.10 but i'll give that a go if it has better features. 

So you're saying just download a source of kernel 2.6.29.6 for mandriva 2010 and compile it ? ok, like it will be compatible with the networkmanager and everything right ? i wont have to use shell just to connect to an AP ? Also then i could probably do the same thing for karmic 9.10. I had thought about it before but i havent tried it yet.

Thanks
Bilal

Hi Bilal, 

I have installed mandriva 2010 x64 and after have downloaded a vanilla kernel 2.6.29.6 from kernel.org... compiled using .config from default mandriva's kernel ... (make oldconfig)... make, make modules_install, make install and simply works flawlessly (wep, wpa or so) without need of any shell connection using drakconnect (network manager of mandriva) 
I think that could be possible also with ubuntu ...

Hi Errico,

Thanks i'll give that a try then, downloading mandriva 2010 now. I'll get back with my results later.

Sorry for late response, i ended up installing kubuntu 9.04 with compat-wireless and patched driver provided here: http://forum.aircrack-ng.org/index.php?topic=5755.0

I basically followed the tutorial to install compat-wireless and r8187 driver on kernel 2.6.28-11-generic #42. The problem is that the guy who wrote the thread claims that the compat-wireless driver that he provided meaning rtl8187 driver works good for internet use. But i noticed the same range problem with that driver. So i dont understand how this could have been fixed had I installed mandriva. He claims the opposite: use rtl8187 for surfing and r8187 for cracking. However in my case the former is the culprit of the source of alfa problem and latter is the solution.

Basically even the patched r8187 driver is not working 100% as i tested an AP in windows vista which had 100% internet connectivity on another laptop, the same AP connects in kubuntu 9.04, gets ip everything but no internet surfing. ping fails. 

This happens using Alfa 500mw at -70dbm. Based on my Windows experience with this card, the minimum range for connection is < -73dbm, < -70dbm for full internet activity. And i can vouch for this because i have used access points in india which were typically in -72-68 dbm range. And this is in windows vista. 

Later I used 2 laptops, one with windows vista and other with linux. Windows one connected to the AP and browsed while the linux one only connected with the AP but could not browse, and the adaptor was in the same place the whole time. This is linux using the patched r8187 driver which is the only working (in my experience) driver for linux using kernel < 2.6.30. 

So you can see that for me, patched r8187 driver is the solution with no problems however it seems that maybe it has problems connecting to some far APs that typically will connect in windows. And for others it seems that using vanilla kernel or compat-wireless seems to solve the problem but have you tried to use the AP which is close to the limits of your card's range with successful internet browsing ? I would like to see people post their RSSI and mention the driver and kernel so that i can get an idea.

For future developments, i own both 500mw and 1000mw versions of the Alfa awus036h and if you like i can run tests for you. Up to date, the latest kernel 2.6.32 also does not have a fix and those wishing to use linux with alfa need to use kernel < 2.6.30 or stick with APs that are close enough or just use your laptops's built in wireless.

Hi Bilal, I have not news about this driver. 
I read on various forums of this problem with rtl8187  with far AP, but without particular solutions except to use the PID algorithm instead of minstrel.

I do not like to use the closed driver provided by Realtek, for now I use rtl8187 driver from kernel 2.6.29.6 with algorithm minstrel...

I think that bug http://bugzilla.kernel.org/show_bug.cgi?id=15123 it's a duplicate of this report...

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

Already compiled and tested latest vanilla kernel 2.6.33, the problem is the same as well 2.6.30 - 2.6.31 - 2.6.32 ...

I have connection, IP address via DHCP but no traffic. 

The problem is already reported in several forums 

Back again to 2.6.29.6  :-(

yes, ultimately it has to be fixed in the kernel itself, only then all other distributions will get this driver fully operational. It also explains why other distributions have failed to do anything about this error even though it has been extensively reported.

On a side note the latest alfa awus036nh which is 2mw in power and relies on the rt3070 chipset, seems to work pretty well with the latest kernels. I havent confirmed it myself but i have read some forum posts where users seems to get it working. In the future i will probably buy that one so im hoping this is true.

details here: http://www.alfa.com.tw/in/front/bin/ptdetail.phtml?Part=AWUS036NH&Category=105463

However i still hope they work on fixing the rtl8187 model for the newer kernels.

Kubuntu 9.04 till then :)

Already tested latest Realtek's r8187l driver (ver 1039 released 27/01/2010) against 2.6.31.12 kernel ...
This driver is working but is rather deaf, I can only receive few AP who have the strongest signals... :-( 
I think that I will buy latest awus 036nh with rt3070 chip ...

Good news ... 
I have a workaround that finally works pretty well and now I can use latest kernel with my Alfa 036H usb interface ...

Simply must manually reduce the data rate of the connection when the signal is less than -70 -72  dBm with: (as root user) (my interface is wlan1)

iwconfig wlan1 rate 5.5M auto

For lower (-75 -77 dBm) signals use 1Mbit/sec 

iwconfig wlan1 rate 1M auto 


I have an usable connection lower to -82 dBM (very weak signal indeed!) using 1Mb/sec rate... My download speed is about 100 <-> 200 KB/sec (really good) 

It is often necessary to repeat the command several times (4 or 5) and verify with iwconfig that the command had the desired effect on rate settings...

My iwconfig is like this:

wlan1     IEEE 802.11bg  ESSID:"Sitecom"  
          Mode:Managed  Frequency:2.427 GHz  Access Point: xx:xx:xx:xx:xx   
          Bit Rate=1 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=36/70  Signal level=-74 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0


Bye E.P.

The minstrel algorithm concentrates on results, not signal strength.  But, I'll copy Felix just in case he has some insight...

I've looked at the rtl8187 driver sources and it seems that the tx status reporting is *really* fragile and inaccurate. I don't know if anything can be done to fix this, I didn't find any sane tx status reporting mechanism in the datasheet or vendor code. 

Maybe it would help a bit to enable the rate fallback in the hardware and report retransmissions for multiple rates (the driver would need to fake multi-rate retry support by increasing hw->max_rates for that to work).

100-200 KB/sec at -82 dBm sounds rather crappy compared to what other chipsets can do. I think people should be warned not to buy such garbage ;)

Hi Felix, tnx for your interest in improving the rtl8187 driver.

Is good enough for me to get 100-200 KB / sec at -82 dBm and 400-500 KB / sec at -74 dBm (manually reducing the data rate to 5.5 Mb / sec or lower) because I have many APs in my neighborhood with very strong signals (-40 to -50 dBm). 

Which chipset you recommend for greater sensitivity?

I have not done a lot of testing with USB based stuff, but if it has to be USB based, I guess I'd recommend something based on Atheros AR9271

These devices stopped working after kernel 2.6.29, before which they worked well. I've been checking this thread every few weeks for over half a year now, and there hasn't been any development update on it. It has been in assigned state for quite some time - are there plans to fix it?

Given that it seems to be a regression, and these cards are somewhat popular (there are a lot of threads popping up on various distro forums), I thought a fix might not be that far off.

None of the module authors can reproduce the problem, thus we cannot fix it. The point at which the "regression" occurs is not when rtl8187 switched to using the minstrel algorithm, but when mac80211 was changed to require a proper number of tries and the driver was returning 0, not 1, for the RTL8187L chips. The RTL8187B units were correct. At that point, the rate algorithm kept the speed at 1 Mb/s for ALL signals. That was an even more severe regression.

Until someone in the US is willing to loan me one of these failing units, I will not be able to fix it.

There are a new driver (rev 1040) in Relatek web, here:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=24&PFid=1&Level=6&Conn=5&DownTypeID=3&GetDown=false&Downloads=true

I blacklisted the driver rtl8187.ko and installed the last version of Realtek, in my case this driver doesn't work properly, problems: the led of the USB adaptor is always on, the commands iw don't work and the driver locks my laptop when it connects to my wlan. Perhaps I've installed it wrong, but I could install it without any problem. Of course, I'm not an expert, I hope your answers.

Sorry, the link is wrong, right link:
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=24&PFid=1&Level=6&Conn=5&DownTypeID=3&GetDown=false&Downloads=true

Yop, that driver isn't in the kernel -- you'll have to seek support for it from Realtek.  Please don't pollute this bug report with information about that driver or its problems.

Pollute? are you a linux Taliban? Relax boy, relax. I asked Realtek team to solve the problem of rtl8187.ko and they didn't answer me, perhaps if other people do the same we can get solutions, insult me isn't a solution. Remember, this forum is NOT your forum. Clear?

Yop, please take your nonsense elsewhere.  You were not insulted -- you were asked to stay on topic.

(In reply to comment #63)
John is the kernel wireless maintainer. All wireless-related changes to the linux kernel need John's approval and signed-off before they go to Linus. Please read "<kernel-source>/MAINTAINERS".

Larry (one of the in-kernel realtek driver maintainers) has spent substantial amount of time looking into this report; Herton hasn't commented here but I remember a few of us on the kernel wireless mailing list wrote something to the lack of reproducibility to this problem, I think. I haven't been using my rtl8187B much lately, due to my base station machine breaking down a while ago; I am happy to have an eye over reviewing changes, if it comes to that. The verdict still seems unclear if there is a problem and/or how to reproduct it, and what hardware it affects.

BTW, bugzilla is not a "forum". Even if you want to treat this as a "forum", this part of the kernel bugzilla is John's "forum", and if you do not like what he wrote, please go away. Clear?

go away...please take your nonsense elsewhere...Linux will never be successful with end users, a lot of Talibans.

Hi, new to bug reporting, I have the same problem with my Alfa USB card, base don RTL8187.
I use this card on weak signal network. And often does not work on <70dB signals.
The solution I found is to set manuall rate to 1M (since this card RF part seems optimized for the modulation used at 1M), and just need internet connection.
It works pretty well.
I saw on debugfs entry, rc_stats file, the choosen -non working- rate OK counter incrementing. since minstrel never goes (??) a rate under a working one, the false ok packet detection is part of this fail.
In may opinion, ther is a problem on good macket measurement, or report to the upper layer.
Since the only rate working is 1M ... (due to both, better RF design, and better mudulation efficiency ??) the connection does not work without manually set the rate.
I can make further measures if needed.
Hope it will help.

Created attachment 47082 [details]
Proposed patch to fix problem

This bug is very old, but I just discovered this problem. If any users still need this fix, try it and let me know if it helps.

(In reply to comment #68)
> Created an attachment (id=47082) [details]
> Proposed patch to fix problem
> 
> This bug is very old, but I just discovered this problem. If any users still
> need this fix, try it and let me know if it helps.

Thanks Larry, I will dig my card out and give this a try when I get a chance.

Hi all,

I'm using an external high sensitivity USB card ( http://www.awus036h.fr ), that I force to rate 1M to be functionnal, on <70 dBm signals.

This 70dBm rx power, precisely seems to be a constant limit.

I can do some tests based on kernel 2.6.32-xx (ubuntu 10.04 LTS) if neeeded.

I guess many people will need a fix, since this card is really efficient on (very)) weak signals, still a reference ans -hopefully- stll sell.

Cheers, Stéphane

If I understand the situation correctly now, the bug allows the rate to go above 1 Mb/s. The patch should not allow it to higher rates unless it is actually getting success.

Please test. If you report success, this patch will be pushed to mainline and backported all the way to 2.6.30.

Created attachment 47352 [details]
Corrected patch for RTL8187L rate problem

Stéphane Vialle noted a typo in the previous patch, which was setting all other bits in the status rather than clearing the ACK. Thanks.

I can confirm the recently commited fix [1] helps.

Before (I tried on 2.6.37.3) I had only a very low quality wifi link on an RTL8187B with the mainline rtl8187 driver, it barely could even connect at all.

Now it works without issues, and easily shows transfer rates of more than 1 MByte/sec.

The only small problem so far, it connected at 1Mb/sec rate initially, then auto-changed that to 9 Mb/sec. I didn't want to wait if it increases by itself further, so I issued "iwconfig wlan0 rate 54M", it changed to 54 Mb/sec and just continues to stay on this speed.

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6410db593e8c1b2b79a2f18554310d6da9415584

It is amazing that this patch helped your RTL8187B as it is specifically for the RTL8187L and does not touch the B code.

Once you lock the rate at 54M, then the rate-control mechanism is no longer able to change the rate; however, the fact that it works at 54M means that minstrel should get it there.

I have been doing some work with ALFA modifying the vendor driver for their AWUS036H. There are some tricks with gain setting that might help both the B and the L chips.

A commit referencing this bug has been merged for .39-rc1:

commit 6410db593e8c1b2b79a2f18554310d6da9415584
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Mon Feb 28 23:36:09 2011 -0600

    rtl8187: Change rate-control feedback

The changes in dev.c do not seem to be L-specific (changed lines in functions rtl8187_work, rtl8187_probe seem to be used for -L and -B without distinction). Of course I could be wrong, and then it is something else between 2.6.37.3 and 2.6.38.1 that helped.

As for the rate, yes, it does at first start with 1-9M, then automatically picks up to 54M after some time.

Those changes may not seem to be L specific, but they are. The B chip provides the retry count in the TX status information, but the L does not. To get that info for the L variant, a separate register has to be read. For USB devices, that cannot be done at interrupt level, thus rtl8187_work is scheduled to obtain that info for the RTL8187L. Check the last if statement at the bottom of rtl8187_tx_cb().

The patch for mainline referred to in comment #75 fixed a problem for the L that kept the code from ever clearing IEEE80211_TX_STAT_ACK when a TX had failed.

(In reply to comment #76)
> The changes in dev.c do not seem to be L-specific (changed lines in functions
> rtl8187_work, rtl8187_probe seem to be used for -L and -B without
> distinction).
> Of course I could be wrong, and then it is something else between 2.6.37.3
> and
> 2.6.38.1 that helped.

I wrote to the others in linux-wireless that there is some sort of throughput regression in 2.6.35.11 which is fixed by compat-wireless between 2.6.37.4<->2.6.38-rc7 . This is a narrow range than yours but entirely within; so could be related.

The last kernel I ran working correctly would have been 2.6.30.9-x though (I am usually up to date with fedora, and that's the release kernel around Oct 22 2009 when I stopped using my wireless system for an unrelated problem); and the problem I experienced with 2.6.35.11 is just low-throughput (sftp) - while the rate shown is 11Mb/s . putting compat-2.6.38-rc7 on gives a substantially higher throughput, rate same, Singnal higher (-40 to -30 -ish, but only anecdotal and not definitive).

i.e. my experience seems to be:

2.6.30.9-x              ok
<broke at unknown rev>
2.6.35.11               poor     
2.6.37.4                poor
<fix at unknown rev>
2.6.38-rc7              ok

 
> As for the rate, yes, it does at first start with 1-9M, then automatically
> picks up to 54M after some time.

The ratio change (start low then tune up as far as possible on demand) is expected - that's what rate control algorithm does. It should drop back down if you are no longer actively using the connectivity, I think.

Will this patch applied in previous versions of the kernel? I´ve installed a o.s. with kernel series 2.6.32 and I don´t have time to install a new o.s with the kernel series 2.6.38. Thanks in advance.

The patch should apply to any kernel 2.6.30 or later. That has not been tested, but a guess based on when the RTL8187L retry feedback was changed.

(In reply to comment #79)
> Will this patch applied in previous versions of the kernel? I´ve installed a
> o.s. with kernel series 2.6.32 and I don´t have time to install a new o.s
> with
> the kernel series 2.6.38. Thanks in advance.

What about compat-wireless? It should work on 2.6.32, I think. (if you are not familiar with it, compat-wireless is broadly speaking a package consists of only the wireless/bluetooth part of later kernels with some extra glues, etc to build/install against older kernels). That's if you are merely interested in havingworking/improved/more-up-todate drivers without working about whether individual patches actually solve or not solve a particular problem.

Even for trying out patches, sometimes(often?) I do compat-wireless + patches, rather than building a whole new kernel plus modules.

Thanks Hin-Tak Leung, I read something about compact-wireless, even I've found a web where teaches how to install it for Ubuntu 10.04, http://forum.aircrack-ng.org/index.php?topic=5755.msg39141#msg39141 
But I'm afraid for it fails, If it fails Ubuntu won't have connection and I'd have to reinstall it. I prefer to wait and install the next distro Mageia with the tree 2.6.38 (I suppose). While I thought perhaps this patch could be added a new release of the tree 2.6.32, Greg Kroah-Hartman has the responsibility in this tree of Linux Kernel. Perhaps I can contact with him. Hin-Tak I'm not a expert in computers, is that possible? Regards.

(In reply to comment #83)
> But I'm afraid for it fails, If it fails Ubuntu won't have connection and I'd
> have to reinstall it.

:-). Actually it is our responsibility to convince GKH that a patch needs to go into a new stable kernel release if it should be. I don't think it will happen for older kernels as far back as 2.6.32 though.

The authoritative place for compat-wireless is this:
http://www.linuxwireless.org/en/users/Download

It is quite safe. To get rid of it, if it does not work or for any other reasons (like trying out a different versions of compat-wireless as I sometimes do) - and revert to the stock kernel drivers from the distro, you only needs to blow away /lib/modules/<kernel-version>/updates , run "depmod -a" and reboot.

The "/lib/module/<kernel-version>/updates" directory normally does not exist and all the new kernel modules are installed under it (your older kernel modules are *not* overwritten), so you are blowing away something that wasn't there before installation; after running "depmod -a" (which updates the kernel to look for kernel modules elsewhere), the kernel should look for the older kernel modules in the older places.

That said, having a linux-savy friend a phone call away may be a good idea... you never know what might go wrong :-).

This patch is already in wireless-testing and is being backported through the stable and long-term trees. One of those is 2.6.32, so the patch will reach that kernel eventually.

Thanks Hin-Tak Leung, I take your suggestion into consideration, before I install Mageia I'll try it, but now I don't have enough time. Moreover I think Larry has done a great work. This issue was really dificult to resolve. I prefer to wait. Regards.

Jose Manuel

The patch is (seems) included on the new Ubuntu 11.04 (natty), that I tested.

Still with my Alfa external USB device (and signals <70dBm), it does not 'functionally' works fine.
The minstrel algorithm does not choose the *right* speed, but does not stays at 54Mb neither, that is better than before (and the link sometimes works).
1Mb speed works far better than the automatic chosen speed(s).

Another point, the minstrel based its speed choices on TX status, it might therefore be incompatible with TX power (>100mW/20dBm) "boost" (that i used only rarely on very weak connection).

Stéphane

Another try with pretty weak signals.
I confirm that link quality is better, I can connect on AP with signal strength about -74dBm.
But, minstrel still lock on high speed that does not work (54M).

By forcing the 1M speed, the link is usable and faster that at 11M or more, but minstrel rs_stats wrongly believe that higher speed have better bandwidth.

what do you think adding in the rtl8187_work() function the following code, that exist on rtl8180 code?
This will lead to be sure that minstrel_tx_status() function will consider the right sent speed. If rate[1].idx was not given with -1, minstrel will take speed[rates[1].idx] instead of speed[rates[0].idx] as the used speed, that is wrong. 

    info->status.rates[1].idx = -1;

Just a idea, hope it helps.

Could you please attach your dmesg output? I want to see if you have a RTL8187L or RTL8187B. The returned status is very different.

Created attachment 60722 [details]
Test patch to return -1 in status.rates[1] for RTL8187L

Please try this patch. I believe it does what your were suggesting.

Created attachment 60732 [details]
dmesg of Afla USB AWUS036H enumeration.

Hi Larry,
This is what I suggested (you have a newer code version than the main line :-) )
The modification seems not making the link better (but may be necessary anyway).

I tryed to add a timing (retry count) handicap to retryed packet (thinking a timeout > good tx try) and a handicap in case of wrong tx packet (> 7trys, adding again retry count).
It makes things a bit better, but is not satisfying in my opinion (it is not to the driver to do so).

About the chipset, I saw wrong tx packet (I believe) with 0 retry, and believe that 7trys may be transmitted, or not (since this is the max trys), and think it needs to change >MAX to >=MAX in work_8187() ???

I believe that it is the minstrel fault, and the rtl8187 driver is quite fine. Minsterl may not work on very weak connection, and  few IP traffic. In my opinion, it trys too much to sample rates, that causes packet losses.
Minstrel seems to work fine if I'm pinging (5 pings), because there is a lot of packet trys, but while browsing, a packet loss is (seems) very bad, since, it freeze the browsing. For example, browsing while pinging works far better, that no pinging.
Then looking for bette bandwidth instead of a better link (even if TCP and/or IP, will finally fix some packet losses), might not be the best choice in my case ?

Any idea ?
Stéphane

Hi Larry, again,
The pacth is what I meant, but I going through the 8187_work() function, i.e. not where you added it (but may be still a good idea?).
Do not hesitate if you need more information (more printk()..., it takes 15 minute to recompile the module on my netbook, but still can do it :-).
Thanks, Stéphane

Created attachment 60782 [details]
Replacement patch to return -1 in status.rates[1].idx

The previous patch applied to the RYL8187B. This version treats bot 8187B and 8187L.

After some thought and more investigation, I noticed that upper layer ask to try to send each packet at multiple speeds.
This lead to try the higher speed first, and finish to the lower (1Mb), often, just two speeds are selected.

The result will give Minstrel information on the higer speed link quality, AND in case of fail, packet will be sent at 1Mb, just slowing down the connexion, without droping any packet.

The rtl 8187 driver does not handle those multiples rates transfers, and may be one of the reasons why the link is unusable when packet at higer speed are dropped (awaiting, TCP retrys, that may still fail).

I tryed to re _tx(skbuff) in the _work() function, but got kernel panic :-( ... it seems that the skbuf couldn't be sent a second time as it.
I do not have engouh knowledge about those skbuffs and SW environment.

Any thought about that?

Cheers, Stéphane