I'm having an issue with my OpenWRT router maintaining a wireless connection to an access point (a TimeCapsule) in client mode.

The hardware is RaspberryPi B and the wireless adapter is a RTL8192CU chipset, using the package kmod-rtl8192cu. I have this issue after a fresh install of the latest stable image.

After setting up via ethernet and installing the wireless device all works as expected with both interfaces having IPs and able to be pinged. A few minutes after unplugging the ethernet cable (and hoping to then rely on wireless access) the wireless connection seems to drop and the router is unreachable.

Any ideas why this is happening?

The wireless adapter is a RTL8192CU chipset, using the OpenWRT package.

My network config:

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config interface 'lan'
    option ifname 'eth0'
    option proto 'static'
    option gateway '192.168.2.1'
    option dns '192.168.2.1'
    option netmask '255.255.255.0'
    option ipaddr '192.168.3.99'

config globals 'globals'
    option ula_prefix 'fdf9:0cb5:747c::/48'

config interface 'wlan'
    option proto 'static'
    option ipaddr '192.168.2.100'
    option gateway '192.168.2.1'
    option dns '192.168.2.1'

Notice the eht0 IP is switched to a differing subnet (following advice here: https://forum.openwrt.org/viewtopic.php?id=40928) following set up to prevent the wireless dropping instantly on unplugging the ethernet.

My wireless config:

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path 'platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1:1.0'
    option disabled '0'
    option channel 'auto'
    option txpower '20'
    option country 'GB'
    option htmode 'HT40'
    option distance '10'

config wifi-iface
    option network 'wlan'
    option ssid 'BASESTATION'
    option device 'radio0'
    option mode 'sta'
    option bssid 'XX:XX:XX:XX:XX:XX'
    option key 'PASSWORD'
    option encryption 'psk2'

The idea is to have my Pi act as DHCP server and gateway using a USB 4G dongle, and connected to an existing TimeCapsule via wifi to provide external access to connected devices.

(Last edited by tristanc on 17 Jan 2015, 21:48)

I'm guessing there may be something up with the rtl8192cu driver? Reading this http://forum.doozan.com/read.php?6,8618 suggests some power management issues that need to be altered .

Any ideas on this? I'm not sure if there is a deeper issue here as the device doesn't seem to connect as easily as it should...

The output of some tests:

If I ssh in via wifi (following a ifdown wlan ifup wlan issues via a wired connection) and run a ping constantly to the router the wifi connection stays up without eth0 being connected.

If I ping the Pi from an external machine via wifi constantly the connection stays up.

Shortly after (~15secs) I unplug eth0 and pause the ping from an external machine just for a moment, the wireless drops...

This is strange.

(Last edited by tristanc on 16 Jan 2015, 19:15)

Anything reported via dmesg?

[    8.301060] usbcore: registered new interface driver rt2800usb
[    8.315657] rtl8192cu: Chip version 0x11
[    8.458309] rtl8192cu: MAC address: e8:de:27:a6:12:a8
[    8.465203] rtl8192cu: Board Type 0
[    8.470933] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[    8.478596] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[    8.486862] usbcore: registered new interface driver rtl8192cu
[    8.506786] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[    8.510297] rtlwifi: wireless switch is on
[   13.992683] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[   14.002363] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   14.389516] cfg80211: Calling CRDA for country: GB
[   14.417470] cfg80211: Regulatory domain changed to country: GB
[   14.424979] cfg80211:  DFS Master region: ETSI
[   14.429420] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[   14.443462] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[   14.454368] cfg80211:   (5170000 KHz - 5250000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[   14.465395] cfg80211:   (5250000 KHz - 5330000 KHz @ 80000 KHz), (N/A, 2000 mBm), (0 s)
[   14.476545] cfg80211:   (5490000 KHz - 5710000 KHz @ 80000 KHz), (N/A, 2700 mBm), (0 s)
[   14.487861] cfg80211:   (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A)
[   15.579261] rtl8192cu: MAC auto ON okay!
[   15.592999] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[   15.665256] rtl8192cu: Tx queue select: 0x05
[   16.165653] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   16.174201] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   17.340482] wlan0: authenticate with 80:ea:96:f3:21:20
[   17.384028] wlan0: send auth to 80:ea:96:f3:21:20 (try 1/3)
[   17.406734] wlan0: authenticated
[   17.417373] wlan0: associate with 80:ea:96:f3:21:20 (try 1/3)
[   17.435594] wlan0: RX AssocResp from 80:ea:96:f3:21:20 (capab=0x1411 status=0 aid=4)
[   17.447235] wlan0: associated
[   17.454596] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   17.492131] wlan0: Limiting TX power to 20 (20 - 0) dBm as advertised by 80:ea:96:f3:21:20

I can then ping 192.168.2.99 successfully, ethernet cable plugged in. If I stop pinging for 20 seconds or so, then restart the ping they timeout. If I leave it timing out for a bit it comes back to life...

Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
64 bytes from 192.168.2.100: icmp_seq=9 ttl=64 time=890.155 ms
64 bytes from 192.168.2.100: icmp_seq=10 ttl=64 time=2.464 ms
64 bytes from 192.168.2.100: icmp_seq=11 ttl=64 time=2.857 ms

348 packets transmitted, 299 packets received, 14.1% packet loss
round-trip min/avg/max/stddev = 2.352/448.793/17743.137/2385.512 ms

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr B8:27:EB:3E:D5:E2  
          inet addr:192.168.3.99  Bcast:192.168.3.255  Mask:255.255.255.0
          inet6 addr: fe80::ba27:ebff:fe3e:d5e2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:818 errors:0 dropped:0 overruns:0 frame:0
          TX packets:671 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:61162 (59.7 KiB)  TX bytes:365756 (357.1 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:123 errors:0 dropped:0 overruns:0 frame:0
          TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:13368 (13.0 KiB)  TX bytes:13368 (13.0 KiB)

wlan0     Link encap:Ethernet  HWaddr E8:DE:27:A6:12:A8  
          inet addr:192.168.2.100  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::eade:27ff:fea6:12a8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1656 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1386 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:177001 (172.8 KiB)  TX bytes:172057 (168.0 KiB)

The output of dmesg doesn't change over this time.

Another quirk is that if I ssh in to 192.168.2.99 and leave it at the prompt, the connection is incredibly slow / laggy. If I open another terminal, set it to ping 192.168.2.99, the original ssh connection becomes responsive again.

Any help greatly appreciated. For my part I'll try a different wireless adapter (rt2870) which has its issues but works under Raspbian. I'll also see if the RTL8192CU works on that Raspbian install.

Scrub that: https://dev.openwrt.org/ticket/17679    So the RT2870 doesn't work out of the box with the Pi and OpenWRT. I gave it a go and appear to be experiencing the same issue - I can see the card but can't connect to the AP.

The RTL8192CU seems to have issues on Raspbian too - maybe the same issue as I'm describing:

http://www.raspberrypi.org/forums/viewt … CU#p668170

Would the solution suggested (insert "options 8192cu rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1" in to /etc/modprobe.d/8192cu.conf) work on OpenWRT? I can't seem to see a modprobe.d folder.

(Last edited by tristanc on 17 Jan 2015, 23:02)

I have just used the RTL8192CU with a Raspbian SD card (so same hardware as OpenWRT) and it works well.  Notable differences include the LED flashing with traffic.

So I guess there is something up with the 8192CU driver in OpenWRT?

After further investigations I have ruled out any Wireless security issues (I tried to maintain a connection to an unsecured AP). I've also tried adding the /etc/modprobe.d/8192cu.conf file.

The issue remains; after a short period the wireless drops its connection. It shows as connected on the web interface and via iwconfig / ifconfig.

Any ideas?

An update on this should anyone else find it useful when searching.

I couldn't get either of my wifi adapters (two very common chipsets) to work using the standard BB image supplied as of the date of this posting. This uses the 3.10 kernel. A search of these forums and elsewhere indicates there is a general issue with this kernel, OpenWRT and wifi device drivers on the Pi.

The 3.12 kernel used in recent Raspbian distributions works well with the devices I have, and the others mentioned as having difficulties.

The audiculapi OpenWRT distribution given at http://audiculapi.sourceforge.net uses the 3.12 kernel for the Pi. I have no issues with either wifi adapter under this distribution.

I can only conclude that the upgrade from 3.10 to 3.12 kernels solves my issues.

I am now trying to work out how to compile the Barrier Breaker source with the RPi 3.12 kernel in a manner similar to the audiculapi version, including all the extra kmods needed to get things like 3G dongles working.

I have the same issue with this driver/module.

You have to insert "options rtw_power_mgnt=0 rtw_enusbss=0 rtw_ips_mode=1" into the file
"/etc/modules.d/rtl8192cu"
e.g. rtl8192cu options rtw_power_mgnt=0 rtw_enusbss=0

But then dmesg | grep

If the options are added you should see them in "/sys/module/rtl8192cu/parameters"

On the raspberry pi you can check the available parameters with:
modinfo rtl8192cu | grep parm says:
[    9.028819] rtl8192cu: unknown parameter 'options' ignored
[    9.036373] rtl8192cu: unknown parameter 'rtw_power_mgnt' ignored
[    9.044396] rtl8192cu: unknown parameter 'rtw_enusbss' ignored

Therefore I checked the module options with:
$ modinfo rtl8192cu | grep parm
But the output on the Raspberry Pi didn't show any valid options. Can I conclude that the options are still missing?

On my Ubuntu 15.04 System I get the following output:
$ modinfo rtl8192cu | grep parm
parm:           swenc:Set to 1 for software crypto (default 0)
parm:           debug:Set debug level (0-5) (default 0) (int)

So the options tw_power_mgnt, rtw_enusbss, rtw_ips_mode ... aren't available on both systems.

Does anyone know how to recompile this module to enable the options? Or how to add the options?

(Last edited by wisler on 22 Sep 2015, 09:36)