Very poor wifi reliability with 3.8 kernel

Hey all, I’ve been trying to track down why my wifi dongle doesn’t work reliably on boot and think I’ve narrowed it down to the drivers in the official Debian 3.8 kernel being old and buggy.

First, the hardware I’m using:

  • Rev C BeagleBone Black, running the official Debian image from here: http://beagleboard.org/latest-images
    (side question, is the 5-14-2014 image on that page really the most recent official Debian build?)
  • Wifi dongle is an Edimax 7811Un, which is a RTL8192CU chipset. Very popular and works perfectly with a Raspberry Pi.
  • Yes I’m aware of the HDMI ground and power plane issue with wifi dongles, I have the wifi dongle attached to a small USB hub that moves it away from the BBB.

My problem is that the wifi connection never reliably starts on boot. I always have to log in and run ifdown wlan0 & ifup wlan0 to get it to connect. My /etc/network/interfaces is configured in the standard way to access my AP (exactly how I’ve configured Raspberry Pi’s which work fine), and for completeness the block of config looks like:

WiFi Example

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid “my AP name”
wpa-psk “my password”

I ran some experiments to reboot the BBB (just using the reboot command) multiple times and count how often the wifi connection would come up successfully on boot. The results were not good, here’s what I saw:

  • With “auto wlan0” and “allow-hotplug wlan0” in /etc/network/interfaces 6 out of 13 attempts succeeded: success rate of 46%.
  • With only “auto wlan0” in /etc/network/interfces 8 out of 13 attempts succeeded: success rate of 62%.
  • With the dongle connected directly to the USB port (i.e. not through the hub) only 4 out of 13 attempts succeeded: success rate of 31%.

I did all I could to find any information from dmesg and syslog for the failed attempts, but there’s no info there. When the connection works on boot I see messages about the RTL8192CU module and then the wlan connection coming up. When the connection does not work I see the same messages about the RTL8192CU module but none of the wlan connection messages. There are no errors or failures at all in the log. It really feels like a timing or internal issue with the RTL module. If there is some other log I should be looking at please let me know and I will check it out.

For comparison I ran the same test with the same wifi adapter on a Raspberry Pi running the latest Raspbian OS image. It worked fine and brought the wifi connection up all 13 times, success rate of 100%.

At this point I was really confused why the BBB could not reliably bring up a wifi connection at boot. Looking a little closer the big obvious difference between the BBB and Pi is the kernel version. On the Pi it’s using kernel 3.15.3 whereas the BBB is running the 3.8 kernel. Looking at the RTL8192CU source on kernel.org I can’t find the 3.8 kernel source, but at least comparing the 3.10 kernel to mainline there are quite a few fixes in the more recent kernels but not in the older ones.

To really confirm it was the 3.8 kernel I used Robert Nelson’s upgrade script to take my BBB to the 3.15.10-bone7 kernel (script from here https://rcn-ee.net/deb/wheezy-armhf/v3.15.10-bone7/). After upgrading the kernel I ran the same reboot test and surprise, surprise the BBB brought up the wifi connection 13 out of 13 times, success rate of 100%.

So long story short it seems like at least for Realtek adapters the official Debian image’s 3.8 kernel has some serious issues. I’m curious is this a known issue or something being worked on right now?

I noticed on the BBB kernel github there was just recently a commit yesterday to add perhaps a backport of later RTL8192CU drivers to the 3.8 kernel (looking at https://github.com/beagleboard/linux/tree/3.8/drivers/net/wireless/rtl8192cu ). Is this true that later RTL wifi drivers are being ported back to the 3.8 kernel?

Finally, is there any suggestion for what folks who use the RTL8192CU or other RTL wifi adapters should do to use them right now on the BBB? Is the 3.15.10-bone7 kernel stable enough for normal use? (like using GPIO, loading and unloading device tree overlays, etc)

For better or worse the Realtek wifi adapters are quite common (folks like Adafruit only sell Realtek wifi adapters because they are known to work with the Pi) and many folks coming to the BBB from the Pi are likely trying to use them. I have a feeling many of the issues people have getting wifi to work with the BBB are related to problems with the 3.8 kernel driver.

Oh forgot to mention on the hardware side I’m powering the BBB with a 5V 10amp supply so there should be no power issues at all (it’s a bit of a monster supply).

Well instead of reading that huge wall of text I will just say that this has been discussed on these group many times, and disabling hdmi has been proven to fix this issue by multiple people. If thats not an option then add a short USB extension cable to get your wireless device away from the ground plane on the board.

Also for thoroughness, realtek has a very, very poor track record for drivers on Linux for as long as I can remember. Atheros being much better according to many people.

I’m not saying they wont work, because others have been able to use them fine, and they seem happy and all. Just a heads up.

Thanks, please don’t take this the wrong way but that reply really doesn’t help the conversion. If you read the thread I mention:

“- Yes I’m aware of the HDMI ground and power plane issue with wifi dongles, I have the wifi dongle attached to a small USB hub that moves it away from the BBB.”

I also describe that I found the problem is the 3.8 kernel in the official Debian image is very old and has serious RTL8192CU bugs. Upgrading my kernel to 3.15.10 gave me perfect reliability with the RTL8192CU adapter (just like on the Raspberry Pi).

The core question I have is, is the 3.15.10 kernel ready for prime time or is work being done to backport fixed RTL8192CU drivers to the 3.8 kernel (as I saw some recent traffic on the kernel github repo)?

I ask because I’d like to help educate folks on how to get wifi working on the BBB by writing a nice guide for Adafruit’s learning system (like they have for the Raspberry Pi), but right now it doesn’t seem like the official Debian image with the 3.8 kernel is really usable with Realtek adapters.

The way I see it is that you have two options. 1) you can fix the drivers yourself, or 2) use an adapter that is known to have a good track record in Linux.

Also, you can not really compare the beaglebone black to the PI even in this context. They use different ABI’s, and the PI is an older ARM architecture. One which some distro’s no longer support.

As to your question about 3.15.x
https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel the the different branch descriptions as to what each is good at.

3.15.x has been around a while, and from what I understand is fairly stable. It has no cape “support” though. at least not the same as 3.8.x. You can load device tree files etc, but it’s done differently. I’ll have to defer to someone else who actually uses 3.15 though for a full description ( I have been using 3.8.x since early last year ).

Hey all, I've been trying to track down why my wifi dongle doesn't work
reliably on boot and think I've narrowed it down to the drivers in the
official Debian 3.8 kernel being old and buggy.

First, the hardware I'm using:
- Rev C BeagleBone Black, running the official Debian image from here:
http://beagleboard.org/latest-images
(side question, is the 5-14-2014 image on that page really the most recent
official Debian build?)

latest "testing":
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Image_Testing_Snapshots

- Wifi dongle is an Edimax 7811Un, which is a RTL8192CU chipset. Very
popular and works perfectly with a Raspberry Pi.

RTL8192CU's are crap on v3.8.x

- Yes I'm aware of the HDMI ground and power plane issue with wifi dongles,
I have the wifi dongle attached to a small USB hub that moves it away from
the BBB.

My problem is that the wifi connection never reliably starts on boot. I
always have to log in and run ifdown wlan0 & ifup wlan0 to get it to
connect. My /etc/network/interfaces is configured in the standard way to
access my AP (exactly how I've configured Raspberry Pi's which work fine),
and for completeness the block of config looks like:

# WiFi Example
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
    wpa-ssid "my AP name"
    wpa-psk "my password"

I ran some experiments to reboot the BBB (just using the reboot command)
multiple times and count how often the wifi connection would come up
successfully on boot. The results were not good, here's what I saw:
- With "auto wlan0" and "allow-hotplug wlan0" in /etc/network/interfaces 6
out of 13 attempts succeeded: success rate of 46%.
- With only "auto wlan0" in /etc/network/interfces 8 out of 13 attempts
succeeded: success rate of 62%.
- With the dongle connected directly to the USB port (i.e. not through the
hub) only 4 out of 13 attempts succeeded: success rate of 31%.

I did all I could to find any information from dmesg and syslog for the
failed attempts, but there's no info there. When the connection works on
boot I see messages about the RTL8192CU module and then the wlan connection
coming up. When the connection does not work I see the same messages about
the RTL8192CU module but none of the wlan connection messages. There are no
errors or failures at all in the log. It really feels like a timing or
internal issue with the RTL module. If there is some other log I should be
looking at please let me know and I will check it out.

For comparison I ran the same test with the same wifi adapter on a Raspberry
Pi running the latest Raspbian OS image. It worked fine and brought the
wifi connection up all 13 times, success rate of 100%.

At this point I was really confused why the BBB could not reliably bring up
a wifi connection at boot. Looking a little closer the big obvious
difference between the BBB and Pi is the kernel version. On the Pi it's
using kernel 3.15.3 whereas the BBB is running the 3.8 kernel. Looking at
the RTL8192CU source on kernel.org I can't find the 3.8 kernel source, but
at least comparing the 3.10 kernel to mainline there are quite a few fixes
in the more recent kernels but not in the older ones.

To really confirm it was the 3.8 kernel I used Robert Nelson's upgrade
script to take my BBB to the 3.15.10-bone7 kernel (script from here
https://rcn-ee.net/deb/wheezy-armhf/v3.15.10-bone7/). After upgrading the
kernel I ran the same reboot test and surprise, surprise the BBB brought up
the wifi connection 13 out of 13 times, success rate of 100%.

3.15.x has much better usb support over v3.8.x

So long story short it seems like at least for Realtek adapters the official
Debian image's 3.8 kernel has some serious issues. I'm curious is this a
known issue or something being worked on right now?

I noticed on the BBB kernel github there was just recently a commit
yesterday to add perhaps a backport of later RTL8192CU drivers to the 3.8
kernel (looking at
https://github.com/beagleboard/linux/tree/3.8/drivers/net/wireless/rtl8192cu
). Is this true that later RTL wifi drivers are being ported back to the
3.8 kernel?

Finally, is there any suggestion for what folks who use the RTL8192CU or
other RTL wifi adapters should do to use them right now on the BBB? Is the
3.15.10-bone7 kernel stable enough for normal use? (like using GPIO, loading
and unloading device tree overlays, etc)

overlays = v3.8.x

Regards,

Maybe a year ago I threw my realtek dongles in the garbage after pulling my hair out for several days and bought a few cheap atheros ones. I have never had WiFi issues ever again. Plug and play and everything…

Maybe I could have gotten the realtek divers to work but my time was better spent on other things…

As a bonus the atheros dongles support monitoring mode in wireshark so they have proved immensely useful in other regards for sniffing 2.4 GHz traffic at WiFi events…

Alright thanks everyone for the input. It’s a bummer but that’s the state of the world right now it seems.

Just curious though, is the activity in the 3.8 kernel github here any indication that there might be more recent rtl8192cu drivers being backported? https://github.com/beagleboard/linux/tree/3.8/drivers/net/wireless/rtl8192cu

Sure, if you want to backport/support it...

Switch to v3.14.x, cape support is growing daily.

(what overlay/cape feature are you using in 3.8?)

http://elinux.org/Beagleboard:Capes_3.8_to_3.14

Regards,

Thanks, I’ll check out 3.14 to see how it works. I’m not using any cape in particular, but I write a lot of guides for Adafruit’s site and want to do a definitive one on getting wifi to work with the BBB. Unfortunately there’s a ton of outdated or incorrect info floating around from the Angstrom days so there’s a lot of confusion and support issues. Does 3.14 support enabling simple overlays like those that turn on UARTs, SPI, etc? I’d hate to tell folks to switch to the 3.14 kernel to get their wifi to work, only to have them see issues with accessing other parts of the hardware.

3.14 doesn't support overlays, but the major capes will be supported
by custom *.dtb's..

For the lcd7-01-00a3 you'd override the default dtb with:

dtb=<device>-lcd7-01-00a3.dtb

in uEnv.txt

Next, if you want to customize the *.dtb "without rebuilding" the kernel:

https://github.com/RobertCNelson/dtb-rebuilder/tree/3.14-ti

You can see, how i've been trying to "help" users:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack.dts#L30

Regards,

Btw if it helps Tony, i have no problem adding a "adafruit" cape, that
has some default usart/spi/etc settings. But i'm betting you want full
gpio control for your library so that won't work.

Otherwise, your library might also have to generate the *.dts yourself
based on how the end user setup their project. You can grap the
template from the dtb-rebuilder and just issue "make" to generate the
*.dtb (of course they will have to reboot..)

Regards,

Thanks for the tips–I’ll take a look at what you mention. Do you think the overlay manager will eventually make it to the later kernels or is it best to get used to compiling and loading dtb’s?

"eventually"

For most people, once they plug a cape/board into the bone's expansion
headers it stays in. That's who i'm targeting with my v3.14.x branch.
Things on the backend are pretty straight forward for building a new
*.dtb (without re-building the kernel).

One "dream" thing i'd like to see, to make things eaiser for new
users. Some kinda nodejs/html gui to select pinmux based on
fuction/cape. This would call dtb-rebuilder with a custom *.dts, build
it and reboot..

Regards,

Your issue is really strange, I have almost the same setup (but not a C revision, the previous one), but until I get everything configured properly I have been powering the BBB only by USB, and using the same wifi setup (WiFi Example), without installing anything else (fresh debian install), and WiFi works perfectly…

Yeah I actually had a similar thought, a web app to help tell you the current state of the pins and even let you change them by generating and loading the appropriate overlay. Been too busy with other stuff to look at it yet, but maybe it would be easier to just start with something that builds a dts from a desired set of pin functionality instead of trying to build overlays and load them with the cape manager.

I was actually curious, what’s the best way to read the current state of each pin? Would using the debugfs nodes at /sys/kernel/debug/pinctrl/44e10800.pinmux be the easiest way, or do you need to figure out the dtbs that are loaded, decompile them, parse the source, etc?

Just to come back to the wifi performance issue, I found updating the kernel to the latest 3.8 series helped a bit with stability (updated to 3.8.13-bone64 using the /opt/scripts/tools/update_kernel.sh). I added a really simple systemd script to automatically run ‘ifdown wlan0’ and ‘ifup wlan0’ on boot and that helped reliability immensely. I can now bring up my RTL wifi card 10+ times on repeatedly on boot, which is a big improvement and reliable enough for most needs.

Also I just got ahold of an Atheros-based wifi adapter, but I’m finding it also has very poor reliability in 3.8. It’s an AR9271 chipset that uses the ath9k_htc module. It also doesn’t come up reliably on boot like RTL adapter, but luckily the systemd wlan0 restart script seems to make it work well. Just curious though since folks mentioned Atheros cards were much better, is the ath9k_htc module not good with 3.8? Or is it just a deeper issue with the USB system in the 3.8 kernel?