marginal wireless success/issues (adaFruit RTl8192cu dongle)

GoogleGroups
1

I’ve made some progress here, but still things are quite unstable/unusable…if you have any insight or pointers, I’d appreciate them.
In summary I’ve got the AdaFruit dongle to connect sometimes, but the connection is lossy (huge ping delays and many ping drops).

  • setup
    BBB with latest (2013.05.08) image
    AdaFruit RTL8192cu (http://www.adafruit.com/products/814)

  • procedure

  • insert usb wireless dongle

  • reboot

  • lsusb now shows: Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

  • dmesg shows an error: Firmware rtlwifi/rtl8192cufw.bin not available

  • opkg update

  • opkg install linux-firmware-rtl8192cu

  • remove wired lan connection (as per many comments wifi will not be connected with a LAN connection)

  • reboot

  • dmesg shows successful load: Loading firmware rtlwifi/rtl8192cufw.bin

  • ifconfig -a now has a wlan0 interface

  • ensure /var/lib/connman/settings has
    [WiFi]
    Enable=true

  • add a new file /var/lib/connman/wifi.config containing
    [service_home]
    Type = wifi
    Name = yourSSID
    Security = wpa2-psk
    Passphrase = yourPassPhrase

At this point I was able to connect to wireless access point (sometimes…sometimes it would fail to affiliate)

dmesg usually indicated a Reason 2 (previous auth not valid) sometimes Reason 3 (AP offline)

when it was connected:

  • SSH took forever to connect (I terminated it before it completed)

  • ping delays of >1s were normal (from both a PC and BBB)

  • lots of pings were dropped (~50%?) (from both a PC to BBB, and from BBB to router)

  • I saw a flood of ARP requests for the router when I was sniffing on the PC

Somehow this seems similar to this post for ArchLinux: http://archlinuxarm.org/forum/viewtopic.php?f=28&t=5560

In desperation, I did a few things:

  • upgraded connman:
    opkg update
    opkg upgrade connman

  • attempted to disable IPv6, but failed (adding a sysctl and also modifying connman config’s didn’t disable IPv6 across a reboot)

At this point I’m tabling this for a bit…so any pointers would be appreciated, this is a bit frustrating!

-Dale

PS. these were some useful things:

re-read connman config instead of rebooting: systemctl restart connman.service

list access points: /usr/lib/connman/test/test-connman services

list of reason codes: http://www.aboutcher.co.uk/2012/07/linux-wifi-deauthenticated-reason-codes/

2

I have had better luck lately. Not using the Adafruit one but the Edimax one (which is probably the same one).

I tried lots of different things as I mentioned in the thread: https://groups.google.com/forum/embed/?place=forum/beagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums%3Futm_expid%3D6702460-6%26utm_referrer%3Dhttp%3A%2F%2Fbeagleboard.org%2FSupport%2FHardware%2520Support#!category-topic/beagleboard/beaglebone-black/lKjxmSaxR1I

I have found that I had problems if I plug it directly into the USB port. Works better plugged into a hub. Note my current hub is not powered.

Things appear lot faster if I am not connected from the PC to the BBBk with USB

You will not make a connection if you have the hard wired connection made.

It does take awhile before it comes up. I wait until I see the blue light come on and then a little before I do a connect using Putty or Winscp into it.

Most times it does not work if I do a reboot of the processor, need to power cycle.

It will often drop out after long period of time (hour? ) Not sure why. I should maybe look at the Journal right after this to see why. Currently I don’t have the debug connection setup.

Kurt

3

Lossy/slow WiFi with the AdaFruit Dongle (rtl8192cu) seems isolated to Angstrom
I used RobertCNelson’s Debian Wheezy image and without having to install anything for the Adaptor, Wireless was solid (very few dropped pings 397/400 and little delay <100ms typically).
eg. it just worked after properly editing /etc/network/interfaces with the SSID/passphrase

For anyone looking at this later, the majority of Angstrom related WiFi information is on this thread:
https://groups.google.com/forum/#!category-topic/beagleboard/lKjxmSaxR1I

4

Dale,

Did you see the lossy/slow behavior with the realtek drivers or the built-in kernel mainline drivers?

-c

5

Hi C,
A short answer here is that I did not rebuild the realtek drivers from source…Angstrom install was via opkg install, and Debian already had the driver “pre-packaged”
I do understand that many have had success with rebuilding the drivers, but I’m trying to understand the problem (and building some knowledge at the same time)…perhaps this is all a waste if RoberCNelson rebuilt the drivers and included them in his demo image (I’m not sure how I could tell if this is the case).

That said, it looks to me like both Debian Wheezy and Angstrom drivers are the same (although Angstrom drivers have a “thumb2” annotation in modinfo reports).
That said, I’m not a Linux expert here, so perhaps something key is missing?

I also delta’d the firmware binfile (rtlwifi/rtl8192cufw.bin) and it is the same between the distributions.

My current though is Angstrom isn’t setting CRDA with US…but leaving in “World”
Angstrom dmesg:

[ 9.174267] cfg80211: Calling CRDA to update world regulatory domain

[ 9.174331] cfg80211: World regulatory domain updated:

[ 9.174340] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)

[ 9.174351] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

[ 9.174361] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

[ 9.174372] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)

[ 9.174381] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

[ 9.174391] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

Debian dmesg (note that there were de-affiliations here…not sure what that is about):

[ 7.677435] cfg80211: Calling CRDA to update world regulatory domain

[ 102.796616] cfg80211: Calling CRDA for country: US

[ 109.227137] cfg80211: Calling CRDA to update world regulatory domain

[ 119.338498] cfg80211: Calling CRDA to update world regulatory domain

[ 136.946677] cfg80211: Calling CRDA to update world regulatory domain

[ 147.199719] cfg80211: Calling CRDA to update world regulatory domain

This is a bit painful to look at, but shows the differences between Angstrom and Debian:
lsmod | grep rtl — no difference between the two as far as modules (although size is different):

Angstrom:
root@beaglebone:~# lsmod | grep rtl
rtl8192cu 73616 0
rtlwifi 63810 1 rtl8192cu
rtl8192c_common 51159 1 rtl8192cu
mac80211 270414 3 rtlwifi,rtl8192c_common,rtl8192cu
cfg80211 166418 2 mac80211,rtlwifi

Debian:

root@arm:~# lsmod | grep rtl
rtl8192cu 88073 0
rtlwifi 77732 1 rtl8192cu
rtl8192c_common 60842 1 rtl8192cu
mac80211 505859 3 rtlwifi,rtl8192c_common,rtl8192cu
cfg80211 424614 2 mac80211,rtlwifi

A lot of data is snipped here for clarity
all of the modinfo vermagics are:

Angstrom: vermagic: 3.8.13 SMP mod_unload modversions ARMv7 thumb2 p2v8
Debian: vermagic: 3.8.13-bone21 SMP mod_unload modversions ARMv7 p2v8

modinfo cfg80211

Angstrom: srcversion: A222F9E5F52FB76188DF640
Debian: srcversion: FB069E31158F4C36568B4B3

modinfo rtl8192cu

Angstrom: srcversion: 121073B066033BC0F990E22
Debian: srcversion: 121073B066033BC0F990E22

modinfo rtlwifi

Angstrom: srcversion: BA0AC747DDF6CF6A0206365
Debian: srcversion: BA0AC747DDF6CF6A0206365

modinfo mac80211

Angstrom: srcversion: 17E093602D9576A28251F7A
Debian: srcversion: 17E093602D9576A28251F7A

modinfo rtl8192c-common

Angstrom: srcversion: E6FCDEDFF185E90DD643BE4
Debian: srcversion: E6FCDEDFF185E90DD643BE4

modinfo rfkill

Angstrom: srcversion: 71F6DAEB5F9FF0A536C07E5
Debian: srcversion: 71F6DAEB5F9FF0A536C07E5

Angstrom’s opkg list found:

root@beaglebone:/media/BEAGLEBONE# opkg list-installed rtl
kernel-module-dvb-usb-rtl28xxu - 3.8.13-r23a.6
kernel-module-rtl2830 - 3.8.13-r23a.6
kernel-module-rtl2832 - 3.8.13-r23a.6
kernel-module-rtl8187 - 3.8.13-r23a.6
kernel-module-rtl8192c-common - 3.8.13-r23a.6
kernel-module-rtl8192cu - 3.8.13-r23a.6
kernel-module-rtlwifi - 3.8.13-r23a.6
linux-firmware-rtl8192cu - 1:0.0+gitAUTOINC+e98750f0d68d0037ce5a186f7f863a9c13bf773a-r4.2

Debian only really found this:

ii firmware-ralin 0.36+wheezy. all Binary firmware for Ralink wirele

-Dale

6

Dale,

Interesting that Debian does not have the same issue as Angstrom, out of curiosity what version of wpa_supplicant is on debian? I’m not sure what else other than driver & firmware would be causing throughput issues though… i am no expert either though!

-c

7

C,
Yep, I thought it was weird, but I’m not totally sure I’ve ‘proved’ the driver is the same between distributions (although the microcode certainly is).

In re-testing today I discovered that Debian can end up performing poorly…and it seems to be strictly a RFI related? I’m using SeeedStudio’s UartSbee for my FTDI and moving the cable & BBB around caused Angstrom similar delay/drop behavior on Debian!

Angstrom also did better (in fact pretty much as good as Debian) in the same physical position (at least one time)

So at this point I’m led to conclude drivers are probably the same between the two distributions…and that physical positioning is far more important with these drivers than the rebuilt ones most people are using.
In my case the BBB is about 5ft from the AP, and on an angle (dongle side about 2inches off the desk in free space and the power side about 1/4inch). The BBB is not enclosed and I have a SparkFun temp sensor wired to power/I2C on P9.

However my prior testing had the BBB in the same physical location/orientation for both and Angstrom performed poorly and Debian was better…so I’m not sure what to conclude there.

Debian’s wpasupplicant is (from dpkg-query):

Architecture: armhf

Multi-Arch: foreign

Source: wpa (1.0-3)

Version: 1.0-3+b1

Angstrom is still using the default connman configuration (it’s been tough to find docs on it).

FYI my AP is wpa2-psk AES, have another AP that I was going to test with eventually.
Oh and I should mention that Debian does have difficulty affiliating at first, and even stranger Debian’s wireless performs poorly in the following scenario:

  • boot with eth0 connected
  • remove eth0 cable
  • ifconfig eth0 down
  • FYI “netstat -rn” at this point doesn’t show a default route, but I’m only pinging the AP
  • now ping the AP (the “-n” option gives better results presumably since there’s a missing gw for DNS)
    I see ping delay/drops: 33/70 and 89ms to 26sec

So should anyone try to reproduce this, it seems removing the eth0 wired connection is a key variable for Debian (Angstrom’s connman requires a disconnected eth0 as it prioritizes connections)

-Dale