Can't get wifi working in non-gui environment

Question

I'm having trouble getting wifi working on my new RPi2. It works fine when I run X and use wpa_gui, but it's not working on the console, even when using the configuration saved by wpa_gui.

The main difference between the two is that, when wpa_gui runs the show, DHCP works and gets an IP address, and the route table gets a couple of entries, whereas on the console neither happens. Even if I force a static IP, the route table is still empty and wifi still doesn't work.

Some info about my hardware:

• lsusb reports Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
• lsmod lists 8192cu installed, which I believe is the correct driver for this chipset.

My wpa_supplicant.conf looks like this:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
    ssid="YYYYY"
    psk="xxxxxxxx"
    proto=RSN
    key_mgmt=WPA-PSK
    pairwise=CCMP
    auth_alg=OPEN
}

The output of iwconfig is identical in both X and console environments:

wlan0     IEEE 802.11bg  ESSID:"YYYYY"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.412 GHz  Access Point: xx:xx:xx:xx:xx:xx   
          Bit Rate:54 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=68/100  Signal level=45/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

My /etc/network/interfaces file is:

auto lo
iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

There are some slight differences in the processes running: under X there are some extra DBus-related processes running, and they run as user pi, whereas the one that is running in the console is run as user messagebus (104) though curiously this name is not displayed by ps even though it is in /etc/passwd.

Console listing (relevant processes):

root      1709     1  0 22:56 ?        00:00:00 /usr/sbin/ifplugd -i wlan0 -q -f -u0 -d10 -w -I
root      1759     1  0 22:56 ?        00:00:00 /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -W -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplicant.conf
root      1793     1  0 22:56 ?        00:00:00 /sbin/wpa_cli -B -P /var/run/wpa_action.wlan0.pid -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action
104       2100     1  0 22:56 ?        00:00:00 /usr/bin/dbus-daemon --system
root      2229     1  0 22:58 ?        00:00:00 dhclient -v -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases wlan0

X listing:

root      1709     1  0 02:07 ?        00:00:00 /usr/sbin/ifplugd -i wlan0 -q -f -u0 -d10 -w -I
root      1759     1  0 02:07 ?        00:00:00 /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -W -D nl80211,wext -c /etc/wpa_supplicant/wpa_supplicant.conf
root      1793     1  0 02:07 ?        00:00:00 /sbin/wpa_cli -B -P /var/run/wpa_action.wlan0.pid -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action
104       2100     1  0 02:08 ?        00:00:00 /usr/bin/dbus-daemon --system
pi        2361  2338  0 02:16 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session x-session-manager
pi        2366     1  0 02:16 tty1     00:00:00 /usr/bin/dbus-launch --exit-with-session x-session-manager
pi        2367     1  0 02:16 ?        00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
pi        2417     1  1 02:17 tty1     00:00:01 /usr/sbin/wpa_gui
root      2510     1  0 02:17 ?        00:00:00 dhclient -v -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases wlan0

Just thinking about it as I type this - could it be a permissions issue around the pi and messagebus users that's causing something in the network initialisation process (eg. DHCP) to fail in the console?

Answer 1

This is another example of why I think NetworkManager is a nasty piece of business for simple, single connection systems like most people would use on a home LAN.

Getting connected manually is really only a matter of a few commands, but to test this you first must disable NetworkManager or it will screw with you.

sudo service NetworkManager stop

Hopefully it stays that way. I usually just remove it from the system completely, but that is probably not good general advice -- it presumably works for most people most of the time.

Now make sure dhclient isn't running.

sudo dhclient -r

There won't be any output, but ps -C dhclient should now show nothing. To actually connect:

sudo ip link set wlan0 up
sudo wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

This will block on the terminal, which is fine for now because you want to see what happens. To send it straight to background instead, add -B. It is normal for it to report some minor errors/warnings.

From another terminal:

sudo dhclient -v wlan0

This should take a moment and end with you receiving a lease and a local IP address. If that happens, you're online. If it works, you can put those commands in a script. With pis, as mentioned, I just uninstall NetworkManager (and its even uglier cousin, ifplugd) and do a simple check at boot:

if [[ -n "$(ip link | grep wlan)" ]]; then
# Connect wifi if an adapter is connected.
    ip link set wlan0 up
    # `wpa_supplicant` MUST be started `-B`
    wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
    dhclient -nw wlan0
else
# Connect ethernet.
    ip link set eth0 up
    dhclient -nw wlan0
fi

Not as flexible as NM but never fails and is hassle-free. There's a somewhat zanier version of this here.