Larry Vaden <vaden@...> writes:
On Tue, Jul 27, 2010 at 6:33 PM, Phil Savoie <psavoie1783 <at>
rogers.com> wrote:
Beginning DHCP transaction. TRIMMED<< Jul 27 19:32:23 smurf3 NetworkManager: <info> Device 'wlan0' DHCP transaction took too long (>45s), stopping it. Jul 27 19:32:23 smurf3 NetworkManager: <info> wlan0: canceled DHCP transaction, dhcp client pid 30770
It would seem that one possibility is that the AP is not running a DHCP server.
Another is that if the AP is running a DHCP server, it is restricting IP addresses to known clients.
kind regards/ldv _______________________________________________ CentOS mailing list CentOS <at> centos.org http://lists.centos.org/mailman/listinfo/centos
A couple of suggestions:
1) I had very similar problems with some of the Broadcom drivers for my laptop ("transaction took too long"). An easy test is to *BRIEFLY* disable security on the AP and see if your system connects. If the two systems connect then there is a problem syncing with WPA security. A possible alternative is to use ndiswrapper and the Windows driver instead of the native Linux driver. I've been really happy with ndiswrapper even if it means I'm "impure" for using a Windows driver.
2) The actual key exchange is handled by a daemon called wpa_supplicant. It can be finicky. The config files are /etc/sysconfig/wpa_supplicant and /etc/wpa_supplicant/wpa_supplicant.cnf You may have better luck fiddling with some of the settings in the configuration files. As an example, ndiswrapper works better for me with -D wext instead of -D ndiswrapper.
I've also seen restating wpa_supplicant (as root, "service wpa_supplicant restart) fix things. Also, I've had better luck just getting the wpa_supplicant configuration right and not using NetworkManager (service NetworkManager stop). I just do a "ifup wlan0" from the command line.
Cheers, Dave