Hello,
I've been trying to get rtl8192cu work on ARM board I got recently.
While I don't get crashes anymore and I can connect to AP, open
connections, do short transfers, eventually rtl8192cu goes silent
(bulk-IN urbs stop completing, no packets received). Bringing
interface down and back up does not help, I need to rmmod/modprobe to
wake the device.
I noticed that, when doing large transfer (with iperf), "signal avg"
reading from iw started to behave interestingly...
Idle (0.1 sec interval):
signal avg: -75 dBm
signal avg: -68 dBm
signal avg: -72 dBm
signal avg: -73 dBm
signal avg: -74 dBm
signal avg: -75 dBm
signal avg: -75 dBm
signal avg: -75 dBm
signal avg: -75 dBm
signal avg: -74 dBm
While doing TCP transfer, rtl8192cu at RX side (0.1sec intervals):
signal avg: -88 dBm
signal avg: -13 dBm
signal avg: -38 dBm
signal avg: 100 dBm
signal avg: -11 dBm
signal avg: 122 dBm
signal avg: 51 dBm
signal avg: 77 dBm
signal avg: -14 dBm
signal avg: -18 dBm
signal avg: 78 dBm
signal avg: 46 dBm
signal avg: -65 dBm
signal avg: -103 dBm
signal avg: -90 dBm
signal avg: 88 dBm
signal avg: -43 dBm
signal avg: -12 dBm
This keeps on until rtl8129cu goes silent.
I have attached kernel log with rtl8192cu loaded with debug=4.
Connection stops working around timestamp 1377. (Log shows some BUGs
which do appear with debugging on but not without.)
Apparently triggering this hang becomes much harder to trigger when
debug=4 is enabled... probably because debug logging increasing CPU
usage, transfer rate drops to 1Mbit/s and above symptom mostly
disappears. Without debug=4, RX runs at ~28Mbit/s.
-Jussi
On 02/25/2013 10:51 AM, Jussi Kivilinna wrote:
> Hello,
>
> I've been trying to get rtl8192cu work on ARM board I got recently. While I
> don't get crashes anymore and I can connect to AP, open connections, do short
> transfers, eventually rtl8192cu goes silent (bulk-IN urbs stop completing, no
> packets received). Bringing interface down and back up does not help, I need to
> rmmod/modprobe to wake the device.
>
> I noticed that, when doing large transfer (with iperf), "signal avg" reading
> from iw started to behave interestingly...
>
> Idle (0.1 sec interval):
> signal avg: -75 dBm
> signal avg: -68 dBm
> signal avg: -72 dBm
> signal avg: -73 dBm
> signal avg: -74 dBm
> signal avg: -75 dBm
> signal avg: -75 dBm
> signal avg: -75 dBm
> signal avg: -75 dBm
> signal avg: -74 dBm
>
> While doing TCP transfer, rtl8192cu at RX side (0.1sec intervals):
> signal avg: -88 dBm
> signal avg: -13 dBm
> signal avg: -38 dBm
> signal avg: 100 dBm
> signal avg: -11 dBm
> signal avg: 122 dBm
> signal avg: 51 dBm
> signal avg: 77 dBm
> signal avg: -14 dBm
> signal avg: -18 dBm
> signal avg: 78 dBm
> signal avg: 46 dBm
> signal avg: -65 dBm
> signal avg: -103 dBm
> signal avg: -90 dBm
> signal avg: 88 dBm
> signal avg: -43 dBm
> signal avg: -12 dBm
>
> This keeps on until rtl8129cu goes silent.
>
> I have attached kernel log with rtl8192cu loaded with debug=4. Connection stops
> working around timestamp 1377. (Log shows some BUGs which do appear with
> debugging on but not without.)
>
> Apparently triggering this hang becomes much harder to trigger when debug=4 is
> enabled... probably because debug logging increasing CPU usage, transfer rate
> drops to 1Mbit/s and above symptom mostly disappears. Without debug=4, RX runs
> at ~28Mbit/s.
Thanks for the log and the signal average data. All of the BUGs come from a
single debug statement in the source. I will delete that trace call.
Realtek has apparently stopped development on the mac80211-based driver. The
latest version is dated 2011.02.10. The latest driver with Realtek's softmac
stack is 2012.06.22. As the two drivers are totally different, porting the fixes
from one to the other are quite difficult.
My plan is to try to improve rtl8192cu; however, if that does not work, I will
pull it in favor of the version with Realtek's stack. It will, of course, need
to be placed in staging. The downside is that a number of distros do not install
drivers from staging, and all the mac80211 features will be lost. That is the
worst case outcome.
Larry
Quoting Larry Finger <[email protected]>:
> On 03/11/2013 02:17 PM, Jussi Kivilinna wrote:
>> Quoting Jussi Kivilinna <[email protected]>:
>>
>>> Hello,
>>>
>>> I've made some more testing, and noticed that device does not go completely
>>> silent...
>>
>> I can now reproduce this hang without large transfers with
>> 'ifconfig wlan0 up;
>> iw dev wlan0 scan & sleep 0.02; ifconfig wlan0 down'.
>>
>> The large tranfers caused connection to fail sometimes, leading
>> wpa_supplicant
>> to issue scan that is aborted. Manually aborting scan causes
>> device/driver go
>> into this partial silence state too (with beacons/probe requests received).
>>
>> So maybe driver does not do all the required clean-ups for aborted scans?
>
> Have you tested 'ifconfig wlan0 up & sleep 0.02; ifconfig wlan0
> down'? Is the scan part absolutely necessary?
Scan appearently is not necessary, 'ifconfig wlan0 up & sleep 0.02;
ifconfig wlan0 down' is enough. Just doing 'ifconfig wlan0 up;
ifconfig wlan0 down' is enough.
I also tested with monitor interface opened for tcpdump while doing
'ifconfig up&down' on wlan0 and still triggered the issue. Then
turning wlan0 up resulted monitor interface only receiving probe
requests from nearby devices.
-Jussi
Quoting Larry Finger <[email protected]>:
> On 03/11/2013 04:06 PM, Jussi Kivilinna wrote:
>>
>> Scan appearently is not necessary, 'ifconfig wlan0 up & sleep 0.02; ifconfig
>> wlan0 down' is enough. Just doing 'ifconfig wlan0 up; ifconfig
>> wlan0 down' is
>> enough.
>>
>> I also tested with monitor interface opened for tcpdump while doing
>> 'ifconfig
>> up&down' on wlan0 and still triggered the issue. Then turning wlan0
>> up resulted
>> monitor interface only receiving probe requests from nearby devices.
>
> I am in the middle of a long-term test of rtl8192ce, which keeps me
> from running tests of rtl8192cu, but I noticed something strange.
> Does the attached patch help? It is compile tested.
>
That patch alone did not help.. however replacing
_rtl92cu_set_check_bssid() with that new rtl92cu_set_check_bssid()
does fix the issue (patch attached).
But I think _rtl92cu_set_check_bssid() needs to be rechecked since it
has '(IS_NORMAL_CHIP(rtlhal->version))' conditional etc.
-Jussi
On 03/11/2013 04:06 PM, Jussi Kivilinna wrote:
>
> Scan appearently is not necessary, 'ifconfig wlan0 up & sleep 0.02; ifconfig
> wlan0 down' is enough. Just doing 'ifconfig wlan0 up; ifconfig wlan0 down' is
> enough.
>
> I also tested with monitor interface opened for tcpdump while doing 'ifconfig
> up&down' on wlan0 and still triggered the issue. Then turning wlan0 up resulted
> monitor interface only receiving probe requests from nearby devices.
Thanks for the test. Something is not being cleared in the
authentication/association/keying process.
Larry
Quoting Jussi Kivilinna <[email protected]>:
> Hello,
>
> I've made some more testing, and noticed that device does not go
> completely silent...
I can now reproduce this hang without large transfers with 'ifconfig
wlan0 up; iw dev wlan0 scan & sleep 0.02; ifconfig wlan0 down'.
The large tranfers caused connection to fail sometimes, leading
wpa_supplicant to issue scan that is aborted. Manually aborting scan
causes device/driver go into this partial silence state too (with
beacons/probe requests received).
So maybe driver does not do all the required clean-ups for aborted scans?
-Jussi
>
> After device stops working in managed mode, I added monitor
> interface and it receives beacons and other broadcast packets.
> However if I turn on any monitor interface for device, managed
> interface is silent and monitor interface only receives probe
> requests.
>
> Before this condition appears, there is "wlan0: deauthenticated from
> xx:xx:xx:xx:xx:xx (Reason: 2)" with reconnect to AP:
>
<snip>
>
> After which silence strikes. So maybe that signal average bug is not
> related to this connection issue, but driver/device goes in to some
> mixed up state because of disconnect/reconnect?
>
> -Jussi
>
> Quoting Larry Finger <[email protected]>:
>
>>
>> Thanks for the log and the signal average data. All of the BUGs
>> come from a single debug statement in the source. I will delete
>> that trace call.
>>
>> Realtek has apparently stopped development on the mac80211-based
>> driver. The latest version is dated 2011.02.10. The latest driver
>> with Realtek's softmac stack is 2012.06.22. As the two drivers are
>> totally different, porting the fixes from one to the other are
>> quite difficult.
>>
>> My plan is to try to improve rtl8192cu; however, if that does not
>> work, I will pull it in favor of the version with Realtek's stack.
>> It will, of course, need to be placed in staging. The downside is
>> that a number of distros do not install drivers from staging, and
>> all the mac80211 features will be lost. That is the worst case
>> outcome.
>>
>> Larry
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
On 03/12/2013 04:10 AM, Jussi Kivilinna wrote:
>
> That patch alone did not help.. however replacing _rtl92cu_set_check_bssid()
> with that new rtl92cu_set_check_bssid() does fix the issue (patch attached).
>
> But I think _rtl92cu_set_check_bssid() needs to be rechecked since it has
> '(IS_NORMAL_CHIP(rtlhal->version))' conditional etc.
I doubt that that IS_NORMAL_CHIP business affects us - the test chips are not
supposed to be in the wild, but I modified your patch to include that test.
With that patch I am getting watchdog_wq callbacks that force a reconnection
every 6 seconds, but that is due to other changes in my code. The result is a
34% loss of pings, but the connection stays up.
Larry
On 03/11/2013 02:17 PM, Jussi Kivilinna wrote:
> Quoting Jussi Kivilinna <[email protected]>:
>
>> Hello,
>>
>> I've made some more testing, and noticed that device does not go completely
>> silent...
>
> I can now reproduce this hang without large transfers with 'ifconfig wlan0 up;
> iw dev wlan0 scan & sleep 0.02; ifconfig wlan0 down'.
>
> The large tranfers caused connection to fail sometimes, leading wpa_supplicant
> to issue scan that is aborted. Manually aborting scan causes device/driver go
> into this partial silence state too (with beacons/probe requests received).
>
> So maybe driver does not do all the required clean-ups for aborted scans?
Have you tested 'ifconfig wlan0 up & sleep 0.02; ifconfig wlan0 down'? Is the
scan part absolutely necessary?
Larry
Hi, some months ago I reported some bugs about this chipset; now I tried latest stable compat-drivers (3.9-rc2-2-su) with the modified patch by Jussi Kivilinna, and I'm happy to report that it works with my alfa AWUS036NHR on ubuntu 12.10 with kernel 3.5; The card now sustains multiple connection/disconnection cicles, and doesn't go mute, even after changing mac address.
Some problems still remains:
-led is always solid, no blinking whatsoever.
-in monitor mode, every client appears as not associated, even when it really is.
-power/signal strength readings (in networkmanager) seem to be fuzzy, almost inverse; nearest APs have lowest signal representation, while farest ones get strongest signal (this could very well be a networkmanager bug/misrepresentation); signal appears normal when the card is connected (only the reading relative to the connected AP)
I know you're probably understaffed and have a lot of work to do, however if you're willing to have a look at this secondary problems (Mr. Finger perhaps), I'm willing to recompile, test and report back to help squash these bugs.
I'm attaching a debug=5 log to show my tests.
As of now, this chipset/card is usable (signal reading is annoying btw)
Thank you all for your work.
Alessandro Lannocca
-----Messaggio originale-----
Da: [email protected] [mailto:[email protected]] Per conto di Jussi Kivilinna
Inviato: martedì 12 marzo 2013 20.49
A: Larry Finger
Cc: [email protected]; 'George0505'
Oggetto: Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
On 12.03.2013 18:51, Larry Finger wrote:
> On 03/12/2013 04:10 AM, Jussi Kivilinna wrote:
>>
>> That patch alone did not help.. however replacing
>> _rtl92cu_set_check_bssid()
>> with that new rtl92cu_set_check_bssid() does fix the issue (patch
>> attached).
>>
>> But I think _rtl92cu_set_check_bssid() needs to be rechecked since it
>> has '(IS_NORMAL_CHIP(rtlhal->version))' conditional etc.
>
> I doubt that that IS_NORMAL_CHIP business affects us - the test chips
> are not supposed to be in the wild, but I modified your patch to
> include that test.
>
Modified patch works here.
> With that patch I am getting watchdog_wq callbacks that force a
> reconnection every 6 seconds, but that is due to other changes in my
> code. The result is a 34% loss of pings, but the connection stays up.
>
No problems here.. <1% loss and can do large transfers, rtl8192cu being able to reconnect is connection is dropped.
-Jussi
I understand this bugs are lower priority, It's just a huge step forward to have this card in a working state, we'll wait for the rest to get sorted whenever possible.
Thanks
Alessandro Lannocca
-----Messaggio originale-----
Da: Larry Finger [mailto:[email protected]] Per conto di Larry Finger
Inviato: mercoledì 13 marzo 2013 16.26
A: Alessandro Lannocca
Cc: 'Jussi Kivilinna'; [email protected]; 'George0505'
Oggetto: Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)
On 03/13/2013 10:11 AM, Alessandro Lannocca wrote:
> Hi, some months ago I reported some bugs about this chipset; now I tried latest stable compat-drivers (3.9-rc2-2-su) with the modified patch by Jussi Kivilinna, and I'm happy to report that it works with my alfa AWUS036NHR on ubuntu 12.10 with kernel 3.5; The card now sustains multiple connection/disconnection cicles, and doesn't go mute, even after changing mac address.
>
> Some problems still remains:
>
> -led is always solid, no blinking whatsoever.
> -in monitor mode, every client appears as not associated, even when it really is.
> -power/signal strength readings (in networkmanager) seem to be fuzzy,
> almost inverse; nearest APs have lowest signal representation, while
> farest ones get strongest signal (this could very well be a
> networkmanager bug/misrepresentation); signal appears normal when the
> card is connected (only the reading relative to the connected AP)
>
> I know you're probably understaffed and have a lot of work to do, however if you're willing to have a look at this secondary problems (Mr. Finger perhaps), I'm willing to recompile, test and report back to help squash these bugs.
>
> I'm attaching a debug=5 log to show my tests.
>
> As of now, this chipset/card is usable (signal reading is annoying
> btw)
Thanks for the report. That patch will be pushed upstream in a few minutes and will be backported to stable withing a few weeks. I am happy to hear that the patch works with your Alfa AWUS036NHR. In my limited testing with that device, it failed to connect. I feared that the RTL8192RU differed from the RTL8192CU.
I know that improper operation of the LEDs and screwy signal levels are annoying, and I will get to them when I can. At the moment, however, I have more important problems to solve.
Thanks,
Larry
Sorry, attachment was missing.
On 03/11/2013 04:06 PM, Jussi Kivilinna wrote:
>
> Scan appearently is not necessary, 'ifconfig wlan0 up & sleep 0.02; ifconfig
> wlan0 down' is enough. Just doing 'ifconfig wlan0 up; ifconfig wlan0 down' is
> enough.
>
> I also tested with monitor interface opened for tcpdump while doing 'ifconfig
> up&down' on wlan0 and still triggered the issue. Then turning wlan0 up resulted
> monitor interface only receiving probe requests from nearby devices.
I am in the middle of a long-term test of rtl8192ce, which keeps me from running
tests of rtl8192cu, but I noticed something strange. Does the attached patch
help? It is compile tested.
Larry
Hello,
I've made some more testing, and noticed that device does not go
completely silent...
After device stops working in managed mode, I added monitor interface
and it receives beacons and other broadcast packets. However if I turn
on any monitor interface for device, managed interface is silent and
monitor interface only receives probe requests.
Before this condition appears, there is "wlan0: deauthenticated from
xx:xx:xx:xx:xx:xx (Reason: 2)" with reconnect to AP:
[ 22.910000] wlan0: authenticate with xx:xx:xx:xx:xx:xx
[ 22.940000] wlan0: send auth to xx:xx:xx:xx:xx:xx (try 1/3)
[ 22.980000] wlan0: authenticated
[ 23.000000] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1/3)
[ 23.030000] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x411
status=0 aid=2)
[ 23.040000] wlan0: associated
[ 23.050000] cfg80211: Calling CRDA for country: FI
[ 23.080000] cfg80211: Updating information on frequency 2412 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.090000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.100000] cfg80211: Updating information on frequency 2417 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.110000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.120000] cfg80211: Updating information on frequency 2422 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.130000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.140000] cfg80211: Updating information on frequency 2427 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.150000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.160000] cfg80211: Updating information on frequency 2432 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.170000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.180000] cfg80211: Updating information on frequency 2437 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.190000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.200000] cfg80211: Updating information on frequency 2442 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.210000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.220000] cfg80211: Updating information on frequency 2447 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.230000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.240000] cfg80211: Updating information on frequency 2452 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.250000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.260000] cfg80211: Updating information on frequency 2457 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.270000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.280000] cfg80211: Updating information on frequency 2462 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.290000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.300000] cfg80211: Updating information on frequency 2467 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.310000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.320000] cfg80211: Updating information on frequency 2472 MHz
for a 20 MHz width channel with regulatory rule:
[ 23.330000] cfg80211: 2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A
mBi, 2000 mBm)
[ 23.340000] cfg80211: Disabling freq 2484 MHz
[ 23.350000] cfg80211: Regulatory domain changed to country: FI
[ 23.360000] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 23.370000] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 23.380000] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 23.390000] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz),
(N/A, 2000 mBm)
[ 23.400000] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz),
(N/A, 2700 mBm)
After which silence strikes. So maybe that signal average bug is not
related to this connection issue, but driver/device goes in to some
mixed up state because of disconnect/reconnect?
-Jussi
Quoting Larry Finger <[email protected]>:
>
> Thanks for the log and the signal average data. All of the BUGs come
> from a single debug statement in the source. I will delete that
> trace call.
>
> Realtek has apparently stopped development on the mac80211-based
> driver. The latest version is dated 2011.02.10. The latest driver
> with Realtek's softmac stack is 2012.06.22. As the two drivers are
> totally different, porting the fixes from one to the other are quite
> difficult.
>
> My plan is to try to improve rtl8192cu; however, if that does not
> work, I will pull it in favor of the version with Realtek's stack.
> It will, of course, need to be placed in staging. The downside is
> that a number of distros do not install drivers from staging, and
> all the mac80211 features will be lost. That is the worst case
> outcome.
>
> Larry
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
On 12.03.2013 18:51, Larry Finger wrote:
> On 03/12/2013 04:10 AM, Jussi Kivilinna wrote:
>>
>> That patch alone did not help.. however replacing
>> _rtl92cu_set_check_bssid()
>> with that new rtl92cu_set_check_bssid() does fix the issue (patch
>> attached).
>>
>> But I think _rtl92cu_set_check_bssid() needs to be rechecked since it has
>> '(IS_NORMAL_CHIP(rtlhal->version))' conditional etc.
>
> I doubt that that IS_NORMAL_CHIP business affects us - the test chips
> are not supposed to be in the wild, but I modified your patch to include
> that test.
>
Modified patch works here.
> With that patch I am getting watchdog_wq callbacks that force a
> reconnection every 6 seconds, but that is due to other changes in my
> code. The result is a 34% loss of pings, but the connection stays up.
>
No problems here.. <1% loss and can do large transfers, rtl8192cu being
able to reconnect is connection is dropped.
-Jussi
On 03/13/2013 10:11 AM, Alessandro Lannocca wrote:
> Hi, some months ago I reported some bugs about this chipset; now I tried latest stable compat-drivers (3.9-rc2-2-su) with the modified patch by Jussi Kivilinna, and I'm happy to report that it works with my alfa AWUS036NHR on ubuntu 12.10 with kernel 3.5; The card now sustains multiple connection/disconnection cicles, and doesn't go mute, even after changing mac address.
>
> Some problems still remains:
>
> -led is always solid, no blinking whatsoever.
> -in monitor mode, every client appears as not associated, even when it really is.
> -power/signal strength readings (in networkmanager) seem to be fuzzy, almost inverse; nearest APs have lowest signal representation, while farest ones get strongest signal (this could very well be a networkmanager bug/misrepresentation); signal appears normal when the card is connected (only the reading relative to the connected AP)
>
> I know you're probably understaffed and have a lot of work to do, however if you're willing to have a look at this secondary problems (Mr. Finger perhaps), I'm willing to recompile, test and report back to help squash these bugs.
>
> I'm attaching a debug=5 log to show my tests.
>
> As of now, this chipset/card is usable (signal reading is annoying btw)
Thanks for the report. That patch will be pushed upstream in a few minutes and
will be backported to stable withing a few weeks. I am happy to hear that the
patch works with your Alfa AWUS036NHR. In my limited testing with that device,
it failed to connect. I feared that the RTL8192RU differed from the RTL8192CU.
I know that improper operation of the LEDs and screwy signal levels are
annoying, and I will get to them when I can. At the moment, however, I have more
important problems to solve.
Thanks,
Larry