Modify

Opened 3 years ago

Last modified 3 years ago

#18539 new defect

RTL8192cu driver stability issues

Reported by: thewerthfam@… Owned by: developers
Priority: high Milestone: Chaos Calmer 15.05
Component: kernel Version: Trunk
Keywords: kernel driver rtl8192 Cc:

Description

Using a RTL8192cu USB wifi dongle with openwrt r43567. There are a few different situations that make the driver not entirely reliable.

1) some clients don't maintain connections for long periods of time (Suually on less than 15 min). When they loose connection the wifi on the client appears connected still but not traffic will flow. Other clients (HP cromebook) stays connected and passes traffic even while the other client is having problems connecting. The problem client is unable to reconnect till the AP is rebooted. The problem client is a compaq running Ubuntu 14 LTS. Running wifi for years on other access points with no issues. Another problem client is a HP office jet wifi printer- same behaviour as the compaq laptop.
2) some clients are unable to connect to the rtl8192cu powered access point at all. This is a visio 24" smart TV. (Though that same device was able to connect and worked fine when the access point was using the ath9k based usb wifi dongle and same wireless mode and security settings.
3) a thinkpad client running ubuntu 14 with an open connection to the ap status page also maintains a connection with out issue.

Reason for using this adapter is that it appears from the openwrt wiki documents it should allow up to 25 clients. As the ath9k based usb card only allows max of 7.

While researching this issue I've come across other people having problems with the seemingly older rtl8192cu driver. http://blog.stuffedcow.net/2014/04/rtl8192cu-and-linux-3-13-10/ Not sure if there is a new driver that can be pulled into the trunk or a patch.

Below is the relevant wifi settings. If there are specific wireless settings that fix this issue that would be great. I interested in most flexability for various clients to connect to a stable connection vs best possible wifi speed. I have tried different wifi security settings WPA, WPA2, auto cipher, aes cipher and non seem to make a difference.

config wifi-device radio0

option type mac80211
option channel 11
option hwmode 11gn
option path 'soc.3/1c1c000.usb/usb2/2-1/2-1:1.0'
option htmode 'HT20'
list ht_capab 'SHORT-GI-20'
list ht_capab 'SHORT-GI-40'
list ht_capab 'RX-STBC1'
list ht_capab 'DSSS_CCK-40'
option txpower '20'
option country 'US'
option channel '1'

config wifi-iface

option device 'radio0'
option mode 'ap'
option ssid 'BananaPi'
option key '<password>'
option network 'lan'
option encryption 'psk+ccmp'

Attachments (0)

Change History (6)

comment:1 Changed 3 years ago by thewerthfam@…

Since this is an ongoing linux kernel driver issue not likely to be solved here, would this driver from realtek be compatible with the hostapd running on openwrt?

Realtek has an GPL open source driver, several have used to compile on raspbian. Here is a recent git source that appears to be setup to suport compiling on the raspberry. https://github.com/dz0ny/rt8192cu

I'd be interested in setting this up on openwrt as a package if someone could tell me if it will be compatible mac80211. I've build Make files for other packages so will be willing to give it a go for a kernel module.

comment:2 Changed 3 years ago by anonymous

Any Advice here?

comment:3 Changed 3 years ago by anonymous

i have the same problem.my device is x86.but in the raspberry pi the driver is ok.

comment:4 Changed 3 years ago by sbrown

I found that the problem only occurs at HT rates.

After looking at some more wireshark output, the problem seems to be
that the aggregation sessions deadlock when a second one starts before
the first one completes. That would explain why it only occurs in HT
mode.

The sequence on the air before the deadlock is:

STA->AP block ack req
STA->AP ping req
AP->STA block ack resp
AP->STA ping resp
AP->STA block ack req
STA->AP block ack resp

The sequence on the air after the deadlock is:

AP->STA block ack req
STA->AP block ack req
AP->STA block ack resp
STA->AP block ack resp
STA->AP ping req
...
STA->AP ping req (repeats)

If I disable aggregation in the driver with the attached patch, the problem goes away with a performance loss.

diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
index 361435f..c1c9bb5 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -59,6 +59,9 @@ static int rtl92cu_init_sw_vars(struct ieee80211_hw *hw)
        struct rtl_priv *rtlpriv = rtl_priv(hw);
        int err;

+       /* disable aggregation until the deadlock is fixed */
+       hw->flags &= ~IEEE80211_HW_AMPDU_AGGREGATION;
+
        rtlpriv->dm.dm_initialgain_enable = true;
        rtlpriv->dm.dm_flag = 0;
        rtlpriv->dm.disable_framebursting = false;

comment:5 Changed 3 years ago by thewerthfam@…

So with our HT mode its really just 802.11g. I wonder if this HT deadlock happens in AP mode only or client mode too. I wonder how much work this would take to fix properly. A USB based WiFi adpater that works well in 802.11n mode is really worth while.

comment:6 Changed 3 years ago by thewerthfam@…

A USB based WiFi adpater that works well in 802.11n mode AND AP Mode is really worth while.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.