RTL8192CU WIFI --- Actual Progress!

OK, I, like many others, have been beating my head against the wall trying to get reliable WIFI operation using the RTL8192CU (that would be the Realtek/Adafruit dongle) chip-set.

My latest round involved:

  1. Fixing ntp:
    http://derekmolloy.ie/automatically-setting-the-beaglebone-black-time-using-ntp/

  2. Installing the vendor drivers into the kernel using:
    http://www.codealpha.net/864/how-to-set-up-a-rtl8192cu-on-the-beaglebone-black-bbb/

  3. Filling in /etc/network/interfaces so ifconfig would work;

  4. editing connman.conf
    (I think there might be some redundancy in all these config files, but I hit every one)

5)…then additionally doing steps 8b, 8d,8e,8f in:
https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/9KCIs7yqsa8
(this updates wpa_supplicant.conf, among other things)

6)Then… if I was lucky and the wlan0 became associated (might take forever if at all):
/sbin/udhcpc -iwlan0
…to get the IP address from my DNS server.

I went thru a gazillion re-boots, re-running wpa_supplicant manually, etc… with very spotty results/

Then I found it.

After a reboot, I noticed that wpa_supplicant was already running as a service by doing:
pgrep wpa

For gee-whiz, I killed the process, then started up my version:
wpa_supplicant -B -Dwext -iwlan0 -c/etc/wpa_supplicant.conf

then:
wpa_cli

By the time I ran wpa_cli, the adapter was already associated! This was a process that previously took many minutes, to hours, to not at all!

Ok, so then I did:
/sbin/udhcpc -iwlan0

…and the IP address was obtained in seconds.

I repeated this exercise many times tonight, and I can get on my network quickly and reliably. I can fire up a browser and websurf, etc…

The bottom line is that I think it is possible that many folks are having difficulty with feuding wpa_suppliant processes. Nowhere in any of the web guidance for getting WIFI going on the BBB have I seen an advisory to stop the original wpa_supplicant process.

Tonight I wrote a good part of a python script to automate this process. I need to add just a few more lines to it and then figure out the systemd stuff to get it to run by itself automatically on system boot.

This is likely not everybody’s problem, but it is another piece of the puzzle – and it got me going.

Later,
Don

Don - I was able to get reliable wifi with just the vendor drivers (effectively these steps if you are building on the beaglebone, these if you are cross compiling) - Connman will configure and talk to wpa_supplicant for you so the/ etc/wpa_supplicant.conf (and network/intefaces and udhcpc bits) are not required.

If you aren’t using connman, you do need wpa_supplicant.conf and to ensure you have started wpa_supplicant correctly to read that file, but connman will handle wpa, dhcp, and interface setup for you.

-c

forgot the links:

these steps if you are building on the beaglebone, these if you are cross compiling)

Cmicali,

I was actually following in your path. You’ll see that I fixed ntp in my step #1, then followed your instructions in step #2. Since that did not seem to create any joy for me at that time, I did the other stuff.

I’ve got a second BBB that is as yet un-configured. I will re-flash it with the latest image and go through the steps again and see if I have problems in all the same places. If it ends up “just working” after step #2, that will be worth some shrugs.

If I am not mistaken, connman uses wpa_supplicant itself for wifi connections. I assumed that the wpa_supplicant process that I found already running was spawned by connman (or for connman) during boot?

The bonenotes and codealpha posts absolutely were a great help. (THANKS!) I’ll post my experience with the 2nd card to this thread.

(Doing all that stuff on the bone was driving me crazy. I think I am going to set up an Ubuntu VM on my main desktop at home so I can cross-compile!)

Thanks,
Don

OK,

I configured my second BBB. I was able to omit editing the interfaces file, but not much else.

  1. I had to modify your workflow by adding these steps right after the “git” retrieval:

cd /usr/src/kernel
make scripts

  1. After completing the rest of your workflow and re-booting, my card would not connect. I verified that no “iwlan0” socket file had been created in /var/run/wpa_supplicant. There was a “iwlan0” interface reported by ifconfig, however. No IP address had been assigned.

For gee-whiz, I tried doing a “/sbin/udhcpc -iwlan0” to see if an IP addressed would be assigned. No dice.

  1. So, I added the following extra steps, and I was able to get the connection up:

a) pgrep for the wpa_supplicant process and kill it.
b) start my own wpa_supplicant process (wpa_supplicant -B -Dwext -iwlan0 -c/etc/wpa_supplicant.conf)
c) wpa_cli then, one or more “status” commands until I see “completed”
d) manually engage DHCP with /sbin/udhcpc -iwlan0

I cannot explain why I find the additional steps in #3 necessary and you did not. Perhaps your flash load is a few days older than mine and the latest is a bit squirrelly? No idea…

Don

Note: For the heck of it, yesterday I decided to reflash my eMMC with the latest build for Angstrom and redo everything I did before.
(Get 2 uarts to work, Get Sound working, Wifi and finally PWM).

I found that I could use the steps he mentioned, with the addition you did for make scripts and everything appears to be working fine with my Wifi.

Note: On my first go around getting Wifi to work, I pulled my hair out for several days only to figure out it started to work after I removed the hard wired ethernet cable. Although this time around it appeared like it gave me an IP address for Wifi and not the cable… Not sure how it decides which Network to give preference to.

Kurt

OK, so basically you found joy by just doing Cmicali’s procedure and not doing the manual stuff thereafter…
(I consider the “make scripts” stuff to just be just an omission in his documented process, it is necessary. He may have done it while installing something else previously…)

Still not sure why I need the extra steps. It is two cards now…

I’m just going to finish the python automation of my steps and I’ll re-test the necessity of using it any time I do a flash update.

Thanks,
Don

cmicali:

I wanted to report back that I found an interaction with my router. I was running TKIP/CCMP ciphers (which a valid combination for my installation), but I found that if I changed it to TKIP/TKIP, your procedure (without the extra manual stuff I added at the end) works great for me. The “make sources” modification is needed on virgin-flashed cards if it has never been done previously though…

I’ve spent way more time on this that I would like to admit!

thanks,
Don

Interesting! I think wpa_supplicant handles that part of it, so if you need CCMP maybe updating to latest wpa_supplicant and connman could help. Either way, glad you got it working!

I have the ada fruit adapter working on the black under Arch Linux documented here lemoneer labs If you experience strange behavior like being able to connect to wifi, but not being able to connect after power off unless the ethernet cable is plugged in, it has to do with the real time clock. The real time clock is not battery backed and does not maintain time after power off (reboot is fine). This will cause a time stamp check to fail when setting up encryption for wifi. I am currently documenting using an external battery backed real time clock to get around this. In the meantime, I hope this helps.

A little more information about the real time clock. When you have the wired connection up (as might when configuring the wifi), ntp will set the time automatically. This will happen sometime after boot but will be too late for the initialization of wifi. This will lead to strange behavior where the wifi connection works, then stops, then works, etc. Whenever you power off, it will erase the time/date setting and on next boot wifi will not work; however, some time later, ntp will correct the clock. Wifi will automatically come up after the next reboot (not power off) or when you manually bring it up once the correct time/date is set.