Manual WPA networks doesn't connect at boot

[Jeff Rasmussen]

When configuring a wireless network to use WPA outside Gnome Network-manager applet, the network will not reconnect after a reboot without a "/etc/init.d/networking restart"

I moved over to nw-manager for the time being. I set up /etc/network/interfaces with this type of configuration for ath0

iface ath0 auto
iface ath0 inet dhcp
        wpa-driver madwifi
        wpa-ssid homezone
        wpa-key-mgmt WPA-PSK
        wpa-psk "quoted passphrase"
# wpa-psk 0001231203

Renaming the file /etc/udev/rules.d/85-ifupdown.rules so that udev won't read the rules from that file actually solves the problem. It looks like udev starts the network in a way that prevent WPA drivers to load correctly.

[Eamonn Sullivan (eamonn-sullivan)]

What worked for me (I have an atheros chipset, using madwifi) is a /etc/wpa_supplicant.conf like this:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=2
fast_reauth=1
network={
        ssid="YOUR-SSID"
        proto=WPA
        key_mgmt=WPA-PSK
        pairwise=TKIP
        group=TKIP
        psk=(fill in this using wpa_passphrase)
}

And a wpa_supplicant start up script in /etc/init.d like this:

#!/bin/sh
# wifi wpa_supplicant init
echo "* [Wifi] enabling wpa_supplicant..."
if [ -x /sbin/wpa_supplicant ]; then
        /sbin/wpa_supplicant -B -c/etc/wpa_supplicant.conf -iath0 -Dmadwifi -w
fi

You then have to:

sudo chmod +x /etc/init.d/wifi_wpa.sh (or whatever you called it)

sudo ln -s /etc/init.d/wifi_wpa.sh /etc/rcS.d/S40netwifiwpa

Yes, this should probably be automated.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

Thank you for your bug report. Do you still have this issue with the latest release of Ubuntu ?

[Saivann Carignan (oxmosys)]

I have this problem too, still not resolved.

I'm on Gutsy with all updates, using WPA through the network-manager with a static IP. I have no error message in dmesg about WPA but the network isn't active at reboot, I have to do a /etc/init.d/networking restart to make it works.

My /etc/network/interfaces look like this :

auto eth3
iface eth3 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
wpa-psk ac22b218cf97263ef58887a86f9e32605bd638017a9c4dacd8d80e8f6bd07696
wpa-driver wext
wpa-key-mgmt WPA-PSK
wpa-proto WPA
wpa-ssid strangebanality

When doing a /etc/init.d/networking restart, I get this in dmesg but nothing more :

[ 231.332000] ADDRCONF(NETDEV_UP): eth3: link is not ready
[ 231.392000] ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready
[ 232.480000] ieee80211_crypt: registered algorithm 'TKIP'

Is it really a boot order problem?

[Pierre Phaneuf (pphaneuf)]

I have the following /etc/network/interfaces on my feisty system (installed from the Ubuntu Server CD, if this makes a difference):

auto lo eth0
iface lo inet loopback
iface eth0 inet dhcp
        wpa-ssid peanuts
        wpa-psk thepassword

At boot-up, I do see "Configuring network interfaces" fly by, and it says "OK", but while lo is set up correctly and eth0 is up, it doesn't get an IP address (I assume it didn't do the WPA2 stuff either). Running "sudo /etc/init.d/networking restart" get it working without a hitch.

[Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount)]

I'm moving this as confirmed.

[Saivann Carignan (oxmosys)]

I use wpasupplicant ver. 0.6.0-1 on Ubuntu Gutsy tribe 5, which is installed by default and configured through the gnome-network-admin interface.

I changed the boot priority of /etc/init.d/networking to be one of the first or last init to be launched (because WPAsupplicant is launched through it). It gave no result at all.

I inspected my dmesg output and found interesting outputs :

// On normal boot
Aug 23 22:54:46 zxz-laptop kernel: [ 18.092000] ieee80211_crypt: registered algorithm 'NULL'
Aug 23 22:54:46 zxz-laptop kernel: [ 18.772000] ieee80211: 802.11 data/management/control stack, git-1.1.13
Aug 23 22:54:46 zxz-laptop kernel: [ 18.772000] ieee80211: Copyright (C) 2004-2005 Intel Corporation <email address hidden>
Aug 23 22:54:46 zxz-laptop kernel: [ 18.840000] usbcore: registered new interface driver hci_usb
Aug 23 22:54:46 zxz-laptop kernel: [ 18.852000] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.0kmprq
Aug 23 22:54:46 zxz-laptop kernel: [ 18.852000] ipw2200: Copyright(c) 2003-2006 Intel Corporation
Aug 23 22:54:46 zxz-laptop kernel: [ 18.852000] ACPI: PCI Interrupt 0000:03:03.0[A] -> GSI 17 (level, low) -> IRQ 18
Aug 23 22:54:46 zxz-laptop kernel: [ 18.852000] ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection
Aug 23 22:54:46 zxz-laptop kernel: [ 19.196000] ipw2200: Detected geography ZZA (11 802.11bg channels, 13 802.11a channels)
Aug 23 22:54:46 zxz-laptop kernel: [ 20.824000] ADDRCONF(NETDEV_UP): eth1: link is not ready

//After I typed sudo /etc/init.d/networking restart

Aug 23 23:01:50 zxz-laptop kernel: [ 469.140000] ADDRCONF(NETDEV_UP): eth1: link is not ready
Aug 23 23:01:50 zxz-laptop kernel: [ 469.776000] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Aug 23 23:01:50 zxz-laptop kernel: [ 469.856000] ieee80211_crypt: registered algorithm 'CCMP'
Aug 23 23:02:01 zxz-laptop kernel: [ 480.164000] eth1: no IPv6 routers present

ieee80211 uses the registered algorithm 'NULL' while it boots, but uses CCMP after a "sudo /etc/init.d/networking restart".

It looks like the CCMP algorithm doesn't exist during boot but is ready to use after gdm is started.

[Bob Blanchard (blabj)]

Having same issue - ubuntu feisty - with the following /etc/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant

network={
        ssid="daintylink"
        scan_ssid=1
        key_mgmt=NONE
        wep_key0={wep key}
        wep_tx_keyidx=0
        priority=999
        auth_alg=SHARED
 }

network={
        ssid="airplus"
        scan_ssid=1
        key_mgmt=NONE
        wep_key0={wep key}
        wep_tx_keyidx=0
        priority=998
        auth_alg=SHARED
 }

And the followng entry in /etc/network/interfaces:

auto eth1
iface eth1 inet dhcp
pre-up /sbin/wpa_supplicant -Bw -Dwext -ieth1 -c/etc/wpa_supplicant.conf
post-down /usr/bin/killall -q wpa_supplicant

Again - /etc/init.d/networking restart works... but reboot.. wpa_supplicant and dhclient get launched but interface does not come up!

-Bob

[Eric Donkersloot (ericd)]

I experience the same behaviour with gutsy (I had this problem in Feisty as well):

Ubuntu Version: Ubuntu gutsy (development branch)
Kernel: 2.6.22-12-generic
Hardware: netgear wg111v2 (rtl8187 chipset, using ndiswrapper 1.45)

auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-ssid blahblahblah
wpa-ap-scan 1
wpa-proto RSN
wpa-pairwise CCMP TKIP
wpa-group CCMP TKIP
wpa-key-mgmt WPA-PSK
wpa-psk blahblahblah
post-down killall -q wpa_supplicant

See the attached services.txt as well; could this be caused by services starting in the wrong order ?

[Bob Blanchard (blabj)]

FYI, a workaround that I am using.. in /etc/rc.local I put the following:

sudo ifdown eth1
sudo ifup eth1

(where eth1 is my wireless interface)

[fox (jm-whx)]

I have the same problem with gutsy.

auto ath0
iface ath0 inet dhcp
wpa-psk ***************************
wpa-driver wext
wpa-key-mgmt WPA-PSK
wpa-proto WPA2
wpa-ssid ***************************

/etc/init.d/networking restart works... but reboot.. wpa_supplicant and dhclient get launched but interface gets no IP.

[fox (jm-whx)]

static IP also doesnt work.

[sgtpepper (gszathmari)]

I can confirm this bug on a fresh install of Gutsy

[Olivier Mengué (dolmen)]

I have the same problem on Gutsy, also with an Atheros card (kernel module: ath_pci).
I don't want to use NetWorkManager as it is a desktop computer shared by multiple users and I do not want to give them the wifi password.
ifdown/ifup ath0 works so I will try to use blabj's workaround.

[Olivier Mengué (dolmen)]

This seems to be a duplicate of bug #53387.

[Olivier Mengué (dolmen)]

Sorry, this is bug 53387.

This seems to be a duplicate of bug #50099.

[Eric Donkersloot (ericd)]

"My solution (reached independently) has been to disable the udev rule entirely:
sudo mv /etc/udev/rules.d/85-ifupdown.rules /etc/udev/rules.d/85-ifupdown.rules.bak"

I can confirm this solved the issue.

[Saivann Carignan (oxmosys)]

This workaround solved the issue for me too, great clue!

[Henrik Nilsen Omma (henrik)]

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined.
According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With 7.10 now released, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates .
The bug is not being closed as work will continue on fixing it for the next release, Hardy Heron (8.04). If the state of this bug should change such that it qualifies for the SRU process, please contact the person who originally declined it and ask them to re-evaluate it. To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage .

[Rodney Shupe (rodney-shupe)]

Confirming that the same the disabling of the udev rule worked on my fresh install of Gutsy (7.10)

[James Teh (jteh)]

I also have this problem on a fresh install of Gutsy. I am using ndiswrapper with a RaLink RT61 based card. I have used a module alias to ensure that ndiswrapper gets loaded for the card.

The interface does attempt to come up at boot. "ip a" shows that an IP address has been assigned, but it shows no-carrier and wpa_cli shows disconnected. wpa_supplicant does appear to be running at this point. An ifdown and ifup of the interface fixes the problem. In fact, I have placed an ifdown and ifup into /etc/rc.local to work around the problem.

I don't believe that the udev rule is the cause of the problem, but rather, the point during boot at which it is called. If I ifdown the interface, rmmod ndiswrapper and modprobe ndiswrapper, it comes up just fine automatically. This demonstrates that the udev rule is working correctly. This leads me to believe that wpa_supplicant has some problem running early in the boot sequence.

Is it perhaps trying to write to somewhere on the root partition, which is still mounted read-only at this point? I have had a brief look through the scripts and can't see why it might be doing this, but thought I'd throw it out there nevertheless.

[Reinhard Tartler (siretart)]

did someone check what what consequences removing /etc/udev/rules.d/85-ifupdown.rules has?

The bug commenters have made it pretty clear that the cause is that udev brings up the network interfaces too early. I still suspect that wpasupplicant fails because some kernel crypto modules have not been loaded yet.

[Eric Donkersloot (ericd)]

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

I replaced the following line in /etc/modprobe.d/ndiswrapper:

alias usb:v0846p6A00d*dc*dsc*dp*ic*isc*ip* ndiswrapper

with

alias wlan0 ndiswrapper

When I changed that line, my wireless adapter (Netgear wg111v2) received an ip address from the router. Before that, it would sometimes receive one but most of the time dhclient would time out.
Seems like wpa_supplicant has trouble connecting properly when the interface was not created by it ? Would that be a correct conclusion ?

[Heinrich Kruger (heindsight-deactivatedaccount)]

I have been having the same problem. When I boot up, my eth1 is brought up, but wpa_supplicant is not started, so I have to manually bring eth1 down and up again to get my wireless networking working. Disabling the ifupdown udev rule has fixed the problem, so I'm fairly certain that this bug is caused by udev bringing up the interface too early, so that wpa_supplicant fails to start. I thought perhaps the problem might be that / is still mounted read-only when udev brings up the interface?

Perhaps a fix would be to somehow modify the udev rule so that it does not trigger at boot time? I don't know if there's a way to do this, but surely the intention of this rule is to do hotplugging of network devices after bootup, rather than bringing up interfaces at boot (that's what /etc/init.d/networking is for). So perhaps instead of bringing up the interface, the udev rule should call a script that tests whether the system is booted up already and then brings up the interface.

Here's my interfaces file:

auto lo eth1

iface lo inet loopback

iface eth0 inet dhcp

iface eth1 inet manual
    wpa_roam /etc/wpa_supplicant.conf

iface solis-air inet dhcp

iface huisnet inet static
    address 192.168.0.2
    netmask 255.255.255.0
    broadcast 192.168.0.255

iface default inet dhcp

And my wpa_supplicant.conf:

# allow config file overwrite
update_config=1

# path to UNIX socket control interface
ctrl_interface=/var/run/wpa_supplicant

# scanning mode
ap_scan=2

# auth timeout
dot11RSNAConfigSATimeout=90

# Ad-Hoc home network
network={
    priority=2
    id_str="huisnet"
    scan_ssid=1
    ssid="Hein"
    mode=1
    key_mgmt=NONE
    auth_alg=SHARED
    group=WEP104
    wep_key0=<key>
    wep_tx_keyidx=0
}

# SOLIS_AIR
network={
    priority=2
    id_str="solis-air"
    ssid="SOLIS-AIR"
    scan_ssid=1
    key_mgmt=IEEE8021X
    eap=TTLS
    phase2="auth=PAP"
    identity="<username>"
    password="<password>"
}

# other (open)
network={
    key_mgmt=NONE
}

[Heinrich Kruger (heindsight-deactivatedaccount)]

I have implemented something like what I suggested in my previous comment and it seems to work. I haven't been able to test it as completely as I'd like, but my wireless network is starting correctly at boot now with the 85-ifupdown udev rule enabled.

I wrote a script that tests whether the loopback interface is up before bringing an interface up. The idea being that if lo is not up yet when a network device is added, then presumably the system is booting and /etc/init.d/networking has not been started yet (and when it is started, it will bring up the interface). If lo is up, on the other hand, then
/etc/init.d/networking has been started already and so the new interface should be brought up by the udev rule.

I'm attaching the script with this comment, save it as /etc/udev/ifup.sh (and make it executable, obviously) and then apply the patch to 85-ifupdown.rules (which I'll also upload here).

[Heinrich Kruger (heindsight-deactivatedaccount)]

here's my patch for /etc/udev/rules.d/85-ifupdown.sh

[Saivann Carignan (oxmosys)]

I confirm that the heindsight solution works for my laptop.

[Heinrich Kruger (heindsight-deactivatedaccount)]

My apologies, I am officially an idiot.
The ifup script I uploaded was severely broken, which means using it is more or less equivalent to having the udev rule disabled (that's what happens when I try to code before sunset).

I've fixed the error in the script, but it seems it doesn't work -- the original problem has returned. I don't really understand it. The only explanations I can come up with is that either there's some other stupid mistake in my script, that I'm just not seeing; or lo is actually brought up somewhere before /etc/init.d/networking starts; or it is possible to ping localhost over lo even when lo hasn't been brought up yet.

For what it's worth, I'm attaching the patch to fix my ifup script anyway.

[Heinrich Kruger (heindsight-deactivatedaccount)]

OK, I should have looked more closely at the init scripts before. It turns out that lo is brought up by S08loopback in /etc/rcS.d before udev is started. So testing whether lo is up doesn't do much good.

I have come up with a temporary workaround though. I modified /etc/init.d/networking to touch a file (/var/run/network/started) when networking is started (or restarted), and remove it when networking is stopped. I also changed my udev ifup script to test for this file to determine whether to bring up the interface. It's a horrible hack, and I hope someone can come up with a better solution soon, but for now it works at least.

[Gao Xianchao (gxcmaillist)]

I can confirm this bug on a fresh install of Ubuntu 8.04 beta
Please fix this bug for the peoples who don't use NetworkManager

[Scott James Remnant (Canonical) (canonical-scott)]

Nothing in this bug report suggests a udev bug?

[Heinrich Kruger (heindsight-deactivatedaccount)]

--Scott James Remnant wrote:
>Nothing in this bug report suggests a udev bug?

I agree, I'd say it's an ifupdown bug.

[Heinrich Kruger (heindsight-deactivatedaccount)]

This seems to be a duplicate of bug #44194.
There Roman Yepishev posted a similar (but somewhat more elegant) workaround to what I posted here.