Bug#362745: [pkg-wpa-devel] Bug#362745: wpasupplicant: Managed mode leaves wpa_supplicant running if ifup fails
On Saturday 15 April 2006 18:12, Felix Homann wrote: No DHCPOFFERS received. No working leases in persistent database - sleeping. Here it fails saying: No working leases in persistent database. Exiting. Failed to bring up wlan. The device is not shown as up. The difference is due to different versions of dhclient. While Kel uses dhclient 3.0.3 (probably from the dhcp3-client package) I'm using the one from the dhcp-client package. Temporarily installing dhcp3-client I could reproduce Kel's output. Regards, Felix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362745: [pkg-wpa-devel] Bug#362745: wpasupplicant: Managed mode leaves wpa_supplicant running if ifup fails
Felix Homann wrote: On Saturday 15 April 2006 18:12, Felix Homann wrote: No DHCPOFFERS received. No working leases in persistent database - sleeping. Here it fails saying: No working leases in persistent database. Exiting. Failed to bring up wlan. The device is not shown as up. The difference is due to different versions of dhclient. While Kel uses dhclient 3.0.3 (probably from the dhcp3-client package) I'm using the one from the dhcp-client package. Temporarily installing dhcp3-client I could reproduce Kel's output. Regards, Felix Ah, nice spot Felix, thanks for the info. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362745: [pkg-wpa-devel] Bug#362745: wpasupplicant: Managed mode leaves wpa_supplicant running if ifup fails
On Sat, Apr 15, 2006 at 11:46:47AM +0200, Felix Homann wrote: If ifup fails on an interface configured to use wpasupplicant's managed mode a wpa_supplicant process is left running in the background. The same happens if you interrupt ifup by pressing CTRL-C before it has finished. 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. Perhaps we can add a check in ifupdown.sh if we have already tried to start an instance of wpasupplicant on this interface, and kill it, if it is. That way we can cope with possible changes in configuration. Kel, what do you think? Gruesse, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362745: [pkg-wpa-devel] Bug#362745: wpasupplicant: Managed mode leaves wpa_supplicant running if ifup fails
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]
Bug#362745: [pkg-wpa-devel] Bug#362745: wpasupplicant: Managed mode leaves wpa_supplicant running if ifup fails
On Saturday 15 April 2006 16:38, Kel Modderman wrote: Felix Homann wrote: 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, Not here. 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. No, on my system it reliably fails following my instructions. No DHCPOFFERS received. No working leases in persistent database - sleeping. Here it fails saying: No working leases in persistent database. Exiting. Failed to bring up wlan. The device is not shown as up. Therefore, you must ifdown the iface before attempting to configure it a second time. I can't because it is not up. BTW, in case you have not noticed: I'm already using 0.4.8-3 from incoming. Maybe that's the reason for the slightly different behaviour. Regards, Felix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362745: [pkg-wpa-devel] Bug#362745: wpasupplicant: Managed mode leaves wpa_supplicant running if ifup fails
In pkg-wpa svn there is some workarounds for this, if you like, pull wpasupplicant.ifupdown from there and test it. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
