Am 29.01.2010 02:42, schrieb Ng Oon-Ee:
Hi all, I'm using netcfg and recently have been noticing the following.
When I resume from suspend I call 'netcfg home' which tries to connect to my home's wifi network. ESSID and WEP key are correctly set. It exist with a 'could not obtain IP address error, this is the dmesg:-
Registered led device: iwl-phy0::radio Registered led device: iwl-phy0::assoc Registered led device: iwl-phy0::RX Registered led device: iwl-phy0::TX ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: direct probe to AP 00:14:7c:be:39:ac (try 1) wlan0: direct probe responded wlan0: authenticate with AP 00:14:7c:be:39:ac (try 1) wlan0: authenticated wlan0: associate with AP 00:14:7c:be:39:ac (try 1) wlan0: RX AssocResp from 00:14:7c:be:39:ac (capab=0x471 status=0 aid=1) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present wlan0: deauthenticating from 00:14:7c:be:39:ac by local choice (reason=3)
The weird thing is that when I run 'iwconfig wlan0 essid MYESSID key MYKEY', then run 'netcfg home' again it works no problem. Suggestions for what I can check out are welcome. This happens both on stock kernel and my custom -ice kernel, am up-to-date (without testing for now, due to my openoffice variant not being done yet).
You should try the testing version of netcfg instead: http://mirrors.kernel.org/archlinux/testing/os/any/netcfg-2.5.0rc2-1-any.pkg... This has two advantages: 1) wpa_supplicant is not only used for WPA, buy also for Open and WEP networks. This increases reliability drastically! (Note that using the deprecated iwconfig-method the connection will not be reestablished by the driver once it is lost - upstream linux-wireless developers recommend always using wpa_supplicant) 2) If you also install wpa_actiond (http://mirrors.kernel.org/archlinux/testing/os/i686/wpa_actiond-1.0-1-i686.p..., http://mirrors.kernel.org/archlinux/testing/os/x86_64/wpa_actiond-1.0-1-x86_...), you get the "net-auto-wireless" mode, which not only automatically connects to the right wireless network whenever it is in range, but also deals with temporary connection losses gracefully and transparently (there is a minor bug where it sometimes won't get DHCP, but that can be worked around and is easy to fix for the next version (WPA_OPTS="-W")). It will also connect to a new network when the old one is out of range and the new one comes in range (assuming the networks are configured as profiles). I guess this will make your problem(s) go away. I don't know why James still hasn't released netcfg 2.5, but I guess he has little time lately.