[pi 2] Wireless - rtl8192cu - from working to terrible

[jmmec]

I am brand new to ArchLinux ARM as of today, but have been using X86 ArchLinux for a few months now.

I am having a terrible problem with a WiFi USB adapter (rtl8192cu), and have read multidues of posts about its flakiness, including some history about how the driver has finally been incorporated into the kernel image, but haven't seen anything that addresses the explicit problem below?

1. I've been running Raspbian on a PI2 using an Edimax USB dongle (rtl8192cu) for 2 years now. No problems!

2. Did a fresh install of ArchLinux ARM following the instructions on the Wiki; used this image:

$this->bbcode_second_pass_code('', '
wget http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-2-latest.tar.gz
')

This is the image & 8192cu module loaded from the 'rpi-2-latest' image:

$this->bbcode_second_pass_code('', '
# uname -a
Linux alarmpi 4.4.45-1-ARCH #1 SMP Fri Jan 27 18:52:49 MST 2017 armv7l GNU/Linux

# lsmod | grep -i 8192
8192cu 532414 0
cfg80211 499485 1 8192cu
')

No problems!

The Edimax dongle works perfectly fine using a "netctl" WPA profile. The blue led light on the Edimax blinks with wireless traffic, although I did disable power management via the usual "/etc/modprobe.d" configuration file to get ping times < 10ms.

3. Upgraded the system to pull in latest software (pacman -Syyu). Terrible regression! The blue led light on the Edimax is solid blue so doesn't flash with activity, and ping times and connection drops are awful.

$this->bbcode_second_pass_code('', '
# uname -a
Linux alarmpi 4.9.13-1-ARCH #1 SMP Mon Feb 27 19:43:33 MST 2017 armv7l GNU/Linux

# lsmod | grep -i 8192
rtl8192cu 75878 0
rtl_usb 11407 1 rtl8192cu
rtl8192c_common 52540 1 rtl8192cu
rtlwifi 77575 3 rtl_usb,rtl8192c_common,rtl8192cu
mac80211 634373 4 rtl_usb,rtlwifi,rtl8192cu,rtl8xxxu
')

Below I ping the pi-2 from a machine on the local LAN over wireless. The ping times should be < 10ms as in #1 and #2 above, but they are very high with frequent connection drops.

$this->bbcode_second_pass_code('', '
64 bytes from 192.168.1.101: icmp_seq=3675 ttl=64 time=3.27 ms
64 bytes from 192.168.1.101: icmp_seq=3676 ttl=64 time=3.22 ms
64 bytes from 192.168.1.101: icmp_seq=3677 ttl=64 time=3.10 ms
64 bytes from 192.168.1.101: icmp_seq=3678 ttl=64 time=3.16 ms
64 bytes from 192.168.1.101: icmp_seq=3679 ttl=64 time=1002 ms
64 bytes from 192.168.1.101: icmp_seq=3680 ttl=64 time=999 ms
64 bytes from 192.168.1.101: icmp_seq=3681 ttl=64 time=999 ms
From 192.168.1.106 icmp_seq=3682 Destination Host Unreachable
From 192.168.1.106 icmp_seq=3683 Destination Host Unreachable
From 192.168.1.106 icmp_seq=3684 Destination Host Unreachable
From 192.168.1.106 icmp_seq=3685 Destination Host Unreachable
From 192.168.1.106 icmp_seq=3686 Destination Host Unreachable
From 192.168.1.106 icmp_seq=3687 Destination Host Unreachable
64 bytes from 192.168.1.101: icmp_seq=3688 ttl=64 time=2031 ms
64 bytes from 192.168.1.101: icmp_seq=3689 ttl=64 time=1018 ms
64 bytes from 192.168.1.101: icmp_seq=3690 ttl=64 time=5.24 ms
64 bytes from 192.168.1.101: icmp_seq=3691 ttl=64 time=2.81 ms
64 bytes from 192.168.1.101: icmp_seq=3692 ttl=64 time=3.22 ms
')

Please help?

[bob8889]

I have a very similar problem.
I have Arch Linux Arm installed on a Raspberry Pi B1 with a USB WiFi doogle which uses a rtl8188cu. It uses the same rtl8192cu driver. Before I updated to 4.9.13-1 it worked flawlessly for months.
Since I've ungraded to 4.9.13-1 it continuously cycles through working, to not work, to working, ....
I've gone back to a Arch Linux backup from October, 2016 (4.4.28-1) and everything is working great again.

[jmmec]

doh.... That's not good news.

I'd like to stay with Arch, but need a working USB WiFi, and don't want to backtrack to the original installation software. If anyone has suggesstions on better WiFi dongles that are proven reliable on Arch, then please post suggestions. I'll do some searching tomorrow too....

Thanks!

[WarheadsSE]

This sounds like a kernel/firmware issue, not an "Arch" issue.

[Gusar]

Before, you were using Realtek's vendor driver (8192cu). This is an out-of-kernel driver actually, on desktop systems you need to install it separately, it's just the RPi kernel that has it integrated. But with the 4.9 kernel, your lsmod shows a different driver, the usual in-kernel one (rtl8192cu). And this driver is... not good.

But this weird, I just updated my RPi, which I admittedly haven't done in a while, and got the 4.9 kernel. And there's no sign of rtl8192cu, I still have 8192cu in the /usr/lib/modules/4.9.13-1-ARCH/kernel/drivers/net/wireless/realtek/rtl8192cu/ directory. So no idea how you have rtl8192cu instead.

Well, anyway, try this: Blacklist rtl8192cu and reboot. Then, if it doesn't load automatically, modprobe rtl8xxxu. This is a new driver for all sorts of Realtek USB devices, not just the "cu" variant. It should work much better than rtl8192cu.


Edit: Ok, figured out the weirdness I mentioned above... both 8192cu and rtl8192cu drivers are available. The former is in drivers/net/wireless/realtek/rtl8192cu/, the latter in drivers/net/wireless/realtek/rtlwifi/rtl8192cu/. Together with rtl8xxxu, there are now *three* drivers for the "cu" devices . So take your pick . rtl8xxxu should work well. If it doesn't, you can go back to 8192cu, it'll work as it always has.

[jmmec]

Thanks so much, Gusar, you solved the problem!

I didn't realize that the 8192cu was still available for use, so I switched to it, and now the blue wireless light works, and the ping times are as expected without connection drops:

$this->bbcode_second_pass_code('', '
[root@alarmpi modprobe.d]# uname -a
Linux alarmpi 4.9.13-1-ARCH #1 SMP Mon Feb 27 19:43:33 MST 2017 armv7l GNU/Linux

[root@alarmpi modprobe.d]# lsmod
Module Size Used by
8192cu 560310 0
cfg80211 541023 1 8192cu
bcm2835_rng 2679 0
rng_core 7657 1 bcm2835_rng
bcm2835_gpiomem 3515 0
uio_pdrv_genirq 3456 0
uio 9072 1 uio_pdrv_genirq
fixed 2921 0
sch_fq_codel 9294 6
snd_bcm2835 21551 0
snd_pcm 86520 1 snd_bcm2835
snd_timer 21484 1 snd_pcm
snd 60637 3 snd_timer,snd_bcm2835,snd_pcm
ip_tables 12363 0
x_tables 17452 1 ip_tables
ipv6 384909 22
')

I did try the 'rtl8xxxu' driver but it was worse than the 'rtl8192cu' driver? Below are my notes that I added to file "/etc/modprobe.d/blacklist.conf" explaining my experience:

$this->bbcode_second_pass_code('', '
[root@alarmpi modprobe.d]# cat blacklist.conf
# This is newer but didn't work: solid blue light on dongle and no wireless IP address from
# router; worse than rtl8192cu
blacklist rtl8xxxu

# These are better than rtl8xxxu: solid blue light on dongle, and does obtain an IP
# address from router, but terrible ping & frequent connection drops
blacklist rtl8192cu
blacklist rtl8192c_common
blacklist rtlwifi
')

[bob8889]

Thanks Gusar, WarheadsSE and jmmec.
I copied and pasted the blacklist.conf contents that jmmec created and after a quick reboot now the wifi seems to be working.
It's been working flawlessly for 12 hours so it's looking good.

Thanks everyone for your help.