Re: connecting to a WPA secured wireless network often fails and takes a very long time
- From: Dan Williams <dcbw redhat com>
- To: Darren Albers <dalbers gmail com>
- Cc: networkmanager-list gnome org
- Subject: Re: connecting to a WPA secured wireless network often fails and takes a very long time
- Date: Fri, 22 Sep 2006 13:08:37 -0400
On Fri, 2006-09-22 at 11:03 -0400, Darren Albers wrote:
> On 9/22/06, Dan Williams <dcbw redhat com> wrote:
> > ipw3945 seems to still be somewhat flaky still, given recent reports.
> >
> > One other way to test this is to install Wireshark/Ethereal, and grab
> > packets that come over the air to see if the the AP is actually sending
> > out a DHCP reply.
> >
> > Dan
>
> What is even more wierd is that the log shows that he is receiving a
> DHCPOFFER, but it seems to be ignored... Looking on bughost.org I see
> some similar bug reports for older IPW2200 cards but not for the
> IPW3945.
>
> Ertugrul can you try bringing up the wireless connection without using
> Network Manager by stopping networkmanager and then bringing the
> interface up with wpasupplicant and ifup.
>
> To do this create a wpa_supplicant.conf, here is an example assuming
> you use wpa-tkip
>
> Stop networkmanager
> sudo /etc/dbus-1/event.d/25NetworkManager stop
> Create the wpa_supplicant.conf:
> sudo gedit /etc/wpa_supplicant.conf
> past in the following:
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=0
> eapol_version=1
> ap_scan=2
> fast_reauth=1
> network={
> ssid="Enteryour SSID Here"
> proto=WPA
> key_mgmt=WPA-PSK
> pairwise=TKIP
> group=TKIP
> psk="mypskgoeshere"
> }
>
> Then start wpa_supplicant with:
> sudp wpa_supplicant -Dwext -ieth1 -c/etc/wpa_supplicant.conf -dd
>
> Then open another terminal window and bring up your interface:
> sudo ifup eth1
>
> Does that work reliably?
>
> The reason I am asking you to go through all that is to try and narrow
> down the issue and see why dhclient isn't reliably answering the dhcp
> offer.
Two things that might affect dhclient behavior are (a) routing table
entries when dhclient starts, and (b) options passed to dhclient.
Currently, distro scripts for 'ifup' functionality may do magic things
that NM may need to do as well. Whether these are to work around bugs
in dhclient or are actually required is another question, but it's
something I think we need to figure out. I too have seen behavior where
dhclient is given an OFFER but seemingly ignores that and keeps sending
out DISCOVERS. Usually another connection attempt fixes it, but it's so
intermittent that it's hard to debug, and after all this is wireless and
maybe my neighbor in the next apartment just called somebody up on
his/her 2.4GHz cordless phone... :)
Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]