05-09-2018, 11:48 AM
So I bought an Edimax Wifi dongle with my CM3 kit and thought it would be supported out of the box. I was to be taught otherwise.
I was using the /boot/wifikeyfile.txt method to read a key from the SD card, since I didn't want to bother using a powered USB hub to connect a keyboard AND the dongle.
The dongle was able to scan the networks but not able to actually connect.
The log of wpa_supplicant actually looks like this with the faulty driver:
So I connected the freeplay to a hub with a keyboard and have written the password by hand. It actually does not help at all that you can't unhide the password, especially considering the freaking UK default keyboard layout in RetroPie, thanks for that. I'm from Germany and I use a US layout. But most people can at least write on an US layout with a different keybaord, UK not so much. Btw, you can reconfigure the layout like so: https://wiki.debian.org/Keyboard#Keyboard_configuration
This didn't work either so I needed to go deeper.
On my Arch Linux the dongle worked just fine, so my expectations that Raspbian screwed up intensified.
Even though the dongle is listed as supported in debian:
https://wiki.debian.org/rtl819x#supported-rtl8192cu
The dongle also worked with Arch Linux ARM on the same Rpi3.
I plugged in the SD card with the freeplay image into my pi3 and it worked just fine (besides the shutdown being broken and the terminal resolution being for ants).
The raspberry pi showed the same behavior as the freeplay, so the issue was likely to be in the image.
Apart from the pi3's onboard wifi, which uses the brcmfmac kernel driver, we have rtl8192cu loaded for the Edimax dongle.
Archlinux is using the same kernel driver, but also loads the more recent and recommended rtl8xxxu. (recommendation source: https://github.com/lwfinger/rtlwifi_new/issues/82)
But besides that Arch was also loading a firmware for the dongle:
And this was not the case on the pi3. Even though the firmware was in place! (/lib/firmware/rtlwifi/rtl8192cufw_TMSC.bin on debian)
On Arch the firmware was part of the linux-firmware package, on raspbian / debian it's in the firmware-realtek package.
SO ... something was not loading the firmware. The big WTF moment after a long investigation i found that raspbian is obviously blacklisting rtl8192cu and rtl8xxxu.
Not sure why they do that and why rtl8192cu is loaded anyway but this is the post that decided this
https://github.com/raspberrypi/linux/iss...-283650385
Anyway, removing the blacklist for the drivers I needed made Wifi work just fine without any performance issues. I was able to clone stuff from git and ssh into the freeplay \o/
Maybe this has changed in a kernel update, the freeplay image is using a pretty recent one (4.14.34-v7+) vs 4.9.35-v7+ in stable raspbian.
TL;DR
To fix your Edimax wifi on the freeplay image do the following:
You are welcome.
I was using the /boot/wifikeyfile.txt method to read a key from the SD card, since I didn't want to bother using a powered USB hub to connect a keyboard AND the dongle.
The dongle was able to scan the networks but not able to actually connect.
The log of wpa_supplicant actually looks like this with the faulty driver:
Code:
$ sudo wpa_supplicant -i wlan1 -c /etc/wpa_supplicant/wpa_supplicant.conf
Successfully initialized wpa_supplicant
wlan1: Trying to associate with de:ad:be:ef:13:37 (SSID='My Cool Wifiname 2.4GHz' freq=2417 MHz)
wlan1: CTRL-EVENT-DISCONNECTED bssid=de:ad:be:ef:13:37 reason=0
wlan1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlan1: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE
wlan1: Trying to associate with de:ad:be:ef:13:37 (SSID='My Cool Wifiname 2.4GHz' freq=2417 MHz)
wlan1: CTRL-EVENT-DISCONNECTED bssid=de:ad:be:ef:13:37 reason=0
wlan1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlan1: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE
wlan1: Trying to associate with de:ad:be:ef:13:37 (SSID='My Cool Wifiname 2.4GHz' freq=2417 MHz)
wlan1: CTRL-EVENT-DISCONNECTED bssid=de:ad:be:ef:13:37 reason=0
wlan1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlan1: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE
wlan1: Trying to associate with de:ad:be:ef:13:37 (SSID='My Cool Wifiname 2.4GHz' freq=2417 MHz)
wlan1: CTRL-EVENT-DISCONNECTED bssid=de:ad:be:ef:13:37 reason=0
wlan1: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="My Cool Wifiname 2.4GHz" auth_failures=1 duration=10 reason=CONN_FAILED
wlan1: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlan1: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE
So I connected the freeplay to a hub with a keyboard and have written the password by hand. It actually does not help at all that you can't unhide the password, especially considering the freaking UK default keyboard layout in RetroPie, thanks for that. I'm from Germany and I use a US layout. But most people can at least write on an US layout with a different keybaord, UK not so much. Btw, you can reconfigure the layout like so: https://wiki.debian.org/Keyboard#Keyboard_configuration
This didn't work either so I needed to go deeper.
On my Arch Linux the dongle worked just fine, so my expectations that Raspbian screwed up intensified.
Even though the dongle is listed as supported in debian:
https://wiki.debian.org/rtl819x#supported-rtl8192cu
The dongle also worked with Arch Linux ARM on the same Rpi3.
I plugged in the SD card with the freeplay image into my pi3 and it worked just fine (besides the shutdown being broken and the terminal resolution being for ants).
The raspberry pi showed the same behavior as the freeplay, so the issue was likely to be in the image.
Code:
$ dmesg | grep usbcore
[ 0.061386] usbcore: registered new interface driver usbfs
[ 0.061443] usbcore: registered new interface driver hub
[ 0.061525] usbcore: registered new device driver usb
[ 0.204266] usbcore: registered new interface driver lan78xx
[ 0.204320] usbcore: registered new interface driver smsc95xx
[ 0.635014] usbcore: registered new interface driver usb-storage
[ 0.639055] usbcore: registered new interface driver usbhid
[ 3.541939] usbcore: registered new interface driver rtl8192cu
[ 3.841311] usbcore: registered new interface driver brcmfmac
Apart from the pi3's onboard wifi, which uses the brcmfmac kernel driver, we have rtl8192cu loaded for the Edimax dongle.
Archlinux is using the same kernel driver, but also loads the more recent and recommended rtl8xxxu. (recommendation source: https://github.com/lwfinger/rtlwifi_new/issues/82)
Code:
[34776.341042] usbcore: registered new interface driver rtl8192cu
[34776.347034] usbcore: registered new interface driver rtl8xxxu
But besides that Arch was also loading a firmware for the dongle:
Code:
$ dmesg | grep firmware
[34776.338324] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
And this was not the case on the pi3. Even though the firmware was in place! (/lib/firmware/rtlwifi/rtl8192cufw_TMSC.bin on debian)
On Arch the firmware was part of the linux-firmware package, on raspbian / debian it's in the firmware-realtek package.
SO ... something was not loading the firmware. The big WTF moment after a long investigation i found that raspbian is obviously blacklisting rtl8192cu and rtl8xxxu.
Not sure why they do that and why rtl8192cu is loaded anyway but this is the post that decided this
https://github.com/raspberrypi/linux/iss...-283650385
Anyway, removing the blacklist for the drivers I needed made Wifi work just fine without any performance issues. I was able to clone stuff from git and ssh into the freeplay \o/
Maybe this has changed in a kernel update, the freeplay image is using a pretty recent one (4.14.34-v7+) vs 4.9.35-v7+ in stable raspbian.
TL;DR
To fix your Edimax wifi on the freeplay image do the following:
Code:
sudo rm /etc/modprobe.d/blacklist-rtl8192cu.conf
sudo rm /etc/modprobe.d/blacklist-rtl8xxxu.conf
sudo reboot