rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Jussi Kivilinna]

Quoting Jussi Kivilinna <jussi.kivilinna@iki.fi>:

> 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 <Larry.Finger@lwfinger.net>:
>
>>
>> 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 majordomo@vger.kernel.org
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

On 03/11/2013 02:17 PM, Jussi Kivilinna wrote:
> Quoting Jussi Kivilinna <jussi.kivilinna@iki.fi>:
>
>> 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

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Jussi Kivilinna]

Quoting Larry Finger <Larry.Finger@lwfinger.net>:

> On 03/11/2013 02:17 PM, Jussi Kivilinna wrote:
>> Quoting Jussi Kivilinna <jussi.kivilinna@iki.fi>:
>>
>>> 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

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

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

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

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


[-- Attachment #2: rtl8192cu_modify_check_bssid --]
[-- Type: text/plain, Size: 1109 bytes --]

Index: linux-2.6/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ linux-2.6/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,7 +1377,23 @@ void rtl92cu_card_disable(struct ieee802
 
 void rtl92cu_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
-	/* dummy routine needed for callback from rtl_op_configure_filter() */
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+	u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
+
+	if (rtlpriv->psc.rfpwr_state != ERFON)
+		return;
+
+	if (check_bssid) {
+		reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+		rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
+					      (u8 *) (&reg_rcr));
+		_rtl92cu_set_bcn_ctrl_reg(hw, 0, BIT(4));
+	} else if (!check_bssid) {
+		reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
+		_rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+		rtlpriv->cfg->ops->set_hw_reg(hw,
+					      HW_VAR_RCR, (u8 *) (&reg_rcr));
+	}
 }
 
 /*========================================================================== */

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Jussi Kivilinna]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

Quoting Larry Finger <Larry.Finger@lwfinger.net>:

> 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


[-- Attachment #2: 01-rtl8192cu_set_network_type_with_new_set_check_bssid.patch --]
[-- Type: text/x-diff, Size: 1946 bytes --]



From: Jussi Kivilinna <jussi.kivilinna@iki.fi>


---
 drivers/net/wireless/rtlwifi/rtl8192cu/hw.c |   31 +++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
index 3c6e18c..ee87201 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,11 +1377,28 @@ void rtl92cu_card_disable(struct ieee80211_hw *hw)
 
 void rtl92cu_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
-	/* dummy routine needed for callback from rtl_op_configure_filter() */
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+	u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
+
+	if (rtlpriv->psc.rfpwr_state != ERFON)
+		return;
+
+	if (check_bssid) {
+		reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+		rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
+					      (u8 *) (&reg_rcr));
+		_rtl92cu_set_bcn_ctrl_reg(hw, 0, BIT(4));
+	} else if (!check_bssid) {
+		reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
+		_rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+		rtlpriv->cfg->ops->set_hw_reg(hw,
+					      HW_VAR_RCR, (u8 *) (&reg_rcr));
+	}
 }
 
 /*========================================================================== */
 
+#if 0
 static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
 			      enum nl80211_iftype type)
 {
@@ -1439,12 +1456,22 @@ static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
 		}
 	}
 }
+#endif
 
 int rtl92cu_set_network_type(struct ieee80211_hw *hw, enum nl80211_iftype type)
 {
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
 	if (_rtl92cu_set_media_status(hw, type))
 		return -EOPNOTSUPP;
-	_rtl92cu_set_check_bssid(hw, type);
+
+	if (rtlpriv->mac80211.link_state == MAC80211_LINKED) {
+		if (type != NL80211_IFTYPE_AP)
+			rtl92cu_set_check_bssid(hw, true);
+	} else {
+		rtl92cu_set_check_bssid(hw, false);
+	}
+
 	return 0;
 }
 

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

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



[-- Attachment #2: 01-rtl8192cu_set_network_type_with_new_set_check_bssid.patch --]
[-- Type: text/x-patch, Size: 3848 bytes --]



From: Jussi Kivilinna <jussi.kivilinna@iki.fi>


---
 drivers/net/wireless/rtlwifi/rtl8192cu/hw.c |   31 +++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

Index: wireless-testing-rebased/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
===================================================================
--- wireless-testing-rebased.orig/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ wireless-testing-rebased/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1377,74 +1377,57 @@ void rtl92cu_card_disable(struct ieee802
 
 void rtl92cu_set_check_bssid(struct ieee80211_hw *hw, bool check_bssid)
 {
-	/* dummy routine needed for callback from rtl_op_configure_filter() */
-}
-
-/*========================================================================== */
-
-static void _rtl92cu_set_check_bssid(struct ieee80211_hw *hw,
-			      enum nl80211_iftype type)
-{
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
-	u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
 	struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
-	struct rtl_phy *rtlphy = &(rtlpriv->phy);
-	u8 filterout_non_associated_bssid = false;
+	u32 reg_rcr = rtl_read_dword(rtlpriv, REG_RCR);
 
-	switch (type) {
-	case NL80211_IFTYPE_ADHOC:
-	case NL80211_IFTYPE_STATION:
-		filterout_non_associated_bssid = true;
-		break;
-	case NL80211_IFTYPE_UNSPECIFIED:
-	case NL80211_IFTYPE_AP:
-	default:
-		break;
-	}
-	if (filterout_non_associated_bssid) {
+	if (rtlpriv->psc.rfpwr_state != ERFON)
+		return;
+
+	if (check_bssid) {
+		u8 tmp;
 		if (IS_NORMAL_CHIP(rtlhal->version)) {
-			switch (rtlphy->current_io_type) {
-			case IO_CMD_RESUME_DM_BY_SCAN:
-				reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
-				rtlpriv->cfg->ops->set_hw_reg(hw,
-						 HW_VAR_RCR, (u8 *)(&reg_rcr));
-				/* enable update TSF */
-				_rtl92cu_set_bcn_ctrl_reg(hw, 0, BIT(4));
-				break;
-			case IO_CMD_PAUSE_DM_BY_SCAN:
-				reg_rcr &= ~(RCR_CBSSID_DATA | RCR_CBSSID_BCN);
-				rtlpriv->cfg->ops->set_hw_reg(hw,
-						 HW_VAR_RCR, (u8 *)(&reg_rcr));
-				/* disable update TSF */
-				_rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
-				break;
-			}
+			reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+			tmp = BIT(4);
 		} else {
-			reg_rcr |= (RCR_CBSSID);
-			rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
-						      (u8 *)(&reg_rcr));
-			_rtl92cu_set_bcn_ctrl_reg(hw, 0, (BIT(4)|BIT(5)));
+			reg_rcr |= RCR_CBSSID;
+			tmp = BIT(4) | BIT(5);
 		}
-	} else if (filterout_non_associated_bssid == false) {
+		rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
+					      (u8 *) (&reg_rcr));
+		_rtl92cu_set_bcn_ctrl_reg(hw, 0, tmp);
+	} else {
+		u8 tmp;
 		if (IS_NORMAL_CHIP(rtlhal->version)) {
-			reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
-			rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
-						      (u8 *)(&reg_rcr));
-			_rtl92cu_set_bcn_ctrl_reg(hw, BIT(4), 0);
+			reg_rcr &= ~(RCR_CBSSID_DATA | RCR_CBSSID_BCN);
+			tmp = BIT(4);
 		} else {
-			reg_rcr &= (~RCR_CBSSID);
-			rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
-						      (u8 *)(&reg_rcr));
-			_rtl92cu_set_bcn_ctrl_reg(hw, (BIT(4)|BIT(5)), 0);
+			reg_rcr &= ~RCR_CBSSID;
+			tmp = BIT(4) | BIT(5);
 		}
+		reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
+		rtlpriv->cfg->ops->set_hw_reg(hw,
+					      HW_VAR_RCR, (u8 *) (&reg_rcr));
+		_rtl92cu_set_bcn_ctrl_reg(hw, tmp, 0);
 	}
 }
 
+/*========================================================================== */
+
 int rtl92cu_set_network_type(struct ieee80211_hw *hw, enum nl80211_iftype type)
 {
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
 	if (_rtl92cu_set_media_status(hw, type))
 		return -EOPNOTSUPP;
-	_rtl92cu_set_check_bssid(hw, type);
+
+	if (rtlpriv->mac80211.link_state == MAC80211_LINKED) {
+		if (type != NL80211_IFTYPE_AP)
+			rtl92cu_set_check_bssid(hw, true);
+	} else {
+		rtl92cu_set_check_bssid(hw, false);
+	}
+
 	return 0;
 }
 

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Jussi Kivilinna]

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

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Alessandro Lannocca]

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: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] Per conto di Jussi Kivilinna
Inviato: martedì 12 marzo 2013 20.49
A: Larry Finger
Cc: linux-wireless@vger.kernel.org; '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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

R: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Alessandro Lannocca]

[-- Attachment #1: Type: text/plain, Size: 31 bytes --]

Sorry, attachment was missing.

[-- Attachment #2: wifi.log.gz --]
[-- Type: application/octet-stream, Size: 201267 bytes --]

Re: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Larry Finger]

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

R: rtl8192cu gets confused when scan is aborted by bringing interface down (Re: rtl8192cu goes silent/dead after some time...)

[Alessandro Lannocca]

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:larry.finger@gmail.com] Per conto di Larry Finger
Inviato: mercoledì 13 marzo 2013 16.26
A: Alessandro Lannocca
Cc: 'Jussi Kivilinna'; linux-wireless@vger.kernel.org; '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