Udev does not ifup wireless interface

[nicola.mfb@…]

When enabling wifi udev launches /etc/udev/scripts/network.sh, but eth0 is alread up and not configured, so it skips and does not ifup eth0.

This was reported on
 http://lists.linuxtogo.org/pipermail/openembedded-devel/2009-March/008717.html

It was proposed to use connman, but as it does not support wpa/wpa2 enterprise networks while a plain wpa_supplicant does, this should really be fixed.

[nicola.mfb@…]

I forgot to mention that this is only the "starting point" for a quite completely broken userspace default wpa_supplicant support.

Applying the proposed patch eth0 is handled by udev but when disabling it wpa_supplicant will not die causing some strange problems when the interface comes up again.

As wpa_supplicant may takes time to associate on complex/distant networks udhcpc may fail, it should be launched *after* wpa_supplicant associated, and respawned every time it associate/deassociate (eg. network changed, freerunner out of range for a long time, etc.)

This should be the default, but it seems that in the OE/debian world this may be achieved by wpa-roaming mode, well this is broken too (missing wpa_action?), and it seems in the past it worked as reported on  http://wiki.openmoko.org/wiki/Wireless_Networking

Actually as a workaround I hacked /etc/udev/scripts/network.sh and:
*) when eth0 comes up it launches wpa_supplicant with -W (wait for wpa_cli)
*) and launches wpa_cli -a /etc/wpa_supplicant/wpa_cli.sh
*) when eth0 comes down, it kills udhcpc and the two above daemons.

Udhcpc is *not* spawned by udev, when wpa_supplicant associate, wpa_cli gets notified and launches /etc/wpa_supplicant/wpa_cli.sh that spawns finally udhcpc, so no more timeout.
After that enabling/disabling the wifi resource works quite perfectly.

Regards

Nicola

[TAsn]

We moved to connman as suggested.