Hi Kel, Am Sonntag, 19. August 2007 10:49 schrieb Kel Modderman: > On Sun, 5 Aug 2007 05:28:56 am Jurij Smakov wrote: > > reassign 431657 wpasupplicant > > thanks > > > > On Sat, Aug 04, 2007 at 07:52:46PM +0200, Michael Lansche wrote: > > > Hi Jurij, > > > > > > Am Freitag, 3. August 2007 23:21 schrieb Jurij Smakov: > > > > Ok, that looks pretty regular. Another thing I can suggest is to try > > > > to add a delay (like 'sleep 5') to the start/pre-up branch in the > > > > /etc/wpa_supplicant/ifupdown.sh, right after conf_wpa_supplicant > > > > line. That delay should give the WPA authentication some time to > > > > settle before the dhclient is invoked to obtain an DHCP lease. Let me > > > > know if it helps. > > > > [...] > > > > > your suggestion works. > > > > > > I think this way the boot process is a few seconds slower than with my > > > workaround. > > > > > > Nevertheless I'd like to ask which is now the better respectively the > > > more Debian-like way? > > > > > > Is it now a bug or only a specific problem of my hardware? > > > > I'm not too familiar with wpasupplicant, so I'm going to reassign the > > bug. > > > > wpasupplicant folks: it looks like under some circumstances > > wpasupplicant exits too soon, so the first attempt to obtain DHCP > > lease fails. I've asked Michael to add a delay to > > /etc/wpa_supplicant/ifupdown.sh and it fixed his problem. Please have > > a look at it and advise. > > Adding the 5 second sleep after invoking wpa_supplicant seems weird to me. > > Perhaps the drivers mentioned in this bug thread do not cope well with > allowing wpa_supplicant to start and then have dhclient start immediately > afterwards before being in associated state. > > The current behaviour (for the shown configuration) is to ignore state of > interface, have wpa_supplicant and dhclient start and when association > happens some short time later dhclient succeeds and the network connection > gets established. > > Another possibility is that wpa_supplicant somehow exits after first > invocation, that has not been confirmed in this report though. Even though > the interface failed to come up on boot there should still be a > wpa_supplicant process running, check it with 'ps aux | grep wpa_sup'. > > If it is still running, check its status with 'wpa_cli status'. > > Thanks, Kel.
after removing the line "sleep 5" it doesn't work on boot: Etch-nb:~# ps aux | grep wpa root 2477 0.0 0.0 3664 932 ? Ss 16:21 0:00 /sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.eth2.pid -i eth2 -D wext -c /etc/wpa_supplicant/wpa_supplicant.mynet.conf -C /var/run/wpa_supplicant root 4300 0.0 0.0 2876 764 pts/1 S+ 16:27 0:00 grep wpa Etch-nb:~# wpa_cli status Selected interface 'eth2' bssid=00:0f:c9:02:3f:1c ssid=allnet id=0 pairwise_cipher=TKIP group_cipher=TKIP key_mgmt=WPA-PSK wpa_state=COMPLETED Then I only get a connection after ifdown eth2 followed by ifup eth2. Regards, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
