Felix Homann wrote:
Package: wpasupplicant
Version: 0.4.8-3
Severity: normal
If ifup fails on an interface configured to use wpasupplicant's "managed
mode" a wpa_supplicant process is left running in the background.
And the device is still marked as up in ifstate, so wpa_supplicant has
every right to be active.
The same happens if you interrupt ifup by pressing CTRL-C before it has
finished.
This is *not* the same. I think this is the real flaw; ifupdown cannot
send a "down" signal on a user interrupt.
This has a major effect if you're trying to set up managed mode: If the first
attempt fails the second attempt will fail, too.
Only when you cancel the first attempt manually, IMO.
How to reproduce this behavior:
Break a working "managed mode" setup by commenting out the wpa-passphrase
line:
# /etc/network/interfaces:
iface wlan inet dhcp
wpa-driver wext
wpa-ssid yourssid
wpa-key-mgmt WPA-PSK
# wpa-passphrase Iwonttellyou
wpa-proto WPA
ifup the interface and wait until ifup gives in. You will still have a
wpa_supplicant running in the background
If you ifup the device, and do not cancel the operation manually, the
device is marked up regardless of whether or not the inet method was
successful.
For example:
iface ath0 inet dhcp
wpa-ssid MadWifiAP
#wpa-passphrase foo
# ifup ath0
Internet Systems Consortium DHCP Client V3.0.3
Copyright 2004-2005 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
wifi1: unknown hardware address type 801
wifi0: unknown hardware address type 801
wifi1: unknown hardware address type 801
wifi0: unknown hardware address type 801
Listening on LPF/ath0/00:09:5b:94:51:82
Sending on LPF/ath0/00:09:5b:94:51:82
Sending on Socket/fallback
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 20
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 18
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
# ifup ath0
ifup: interface ath0 already configured
# ifup ath0
ifup: interface ath0 already configured
# ifdown ath0
Internet Systems Consortium DHCP Client V3.0.3
Copyright 2004-2005 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP
wifi1: unknown hardware address type 801
wifi0: unknown hardware address type 801
wifi1: unknown hardware address type 801
wifi0: unknown hardware address type 801
Listening on LPF/ath0/00:09:5b:94:51:82
Sending on LPF/ath0/00:09:5b:94:51:82
Sending on Socket/fallback
DHCPRELEASE on ath0 to 192.168.0.1 port 67
send_packet: Network is unreachable
send_packet: please consult README file regarding broadcast address.
The first attempt failed, yet the device was still marked up, and
ifupdown recorded the state. The wpa_supplicant daemon has every right
to keep running, in the chance that the inet method will eventually succeed.
Therefore, you must ifdown the iface before attempting to configure it a
second time.
If you get impatient and kill the process manually, the state is not
recorded as up, and we hit the problem you describe. We can work around
this by killing these orphans next time we up the iface, but a better
solution would be for ifupdown to send a down signal when it is
interrupted by the user.
Now, uncomment the wpa-passphrase line and try to ifup wlan again. It will
fail.
Only if the first attempt was cut short by manual termination. The issue
here is that we are spawning daemons, these are not sent any "die"
signal when ifupdown is terminated manually.
Anyway, thanks for bringing this up, it is an interesting situation.
Please correct my statements and examples if they are wrong, I have only
just begun investigating it.
Thanks, Kel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
